Fintech & Financial Services
Software engineering for Payment Platforms
Payments is the least forgiving software domain there is. Money must move exactly once, be accounted for to the penny, and keep flowing when everything else is on fire. We build the systems that hold up.
Why the domain matters
Payment platforms are the software that moves money, gateways, acquiring integrations, payment service providers, orchestration layers, ledgers and the settlement and reconciliation machinery behind them. What separates this domain from almost every other kind of software is that a defect is not a degraded experience, it is a financial event. A double charge, a lost settlement, a mis-attributed refund or a few hours of downtime during a peak sales window are not bugs you close quietly: they are money owed, disputes raised, and in some cases a regulator asking questions. We treat payments code with the seriousness that reality demands.
The technical demands cluster around four things: reliability and availability, because payments cannot go down; correctness and reconciliation, because every penny has to be accounted for through idempotency, ledgers, settlement and chargebacks; low latency at high and spiky volume; and fraud and risk, because the moment you move money you become a target. Layered over all of that is compliance. PCI DSS shapes the entire architecture the instant card data is in scope, and PSD2, Strong Customer Authentication, e-money and payment-institution regulation, safeguarding and AML each impose hard constraints that are not negotiable after the fact. These are not features bolted on at the end. They are the shape of the system.
We are engineers, not a licensed processor, and we will tell you plainly what that means. For most businesses the right architecture is to integrate a licensed acquirer or PSP (Stripe, Adyen, Checkout.com and their peers), rather than to build acquiring, hold funds and carry the regulatory licence yourself. Building your own scheme connectivity and safeguarding regime is a multi-year, heavily regulated undertaking that very few businesses should attempt. What we do is the engineering: the integration, the orchestration, the ledger and reconciliation, the fraud tooling and the operational discipline that makes a payment platform correct and dependable. We provide the software and the senior people who operate it; we do not provide the licence, and we will not pretend otherwise.
The challenges in payment platforms
Reliability that has no acceptable downtime
A payment path that is down is a checkout that fails and revenue that stops. Peaks are brutal and correlated (Black Friday, ticket on-sales, payday), exactly when your dependencies are also under load. The hard part is not the happy path; it is degrading gracefully when an acquirer times out, a 3-D Secure step stalls, or a downstream is slow, without dropping or duplicating transactions.
Idempotency and exactly-once money movement
Networks retry, clients retry, and timeouts leave you genuinely unsure whether a charge went through. Without disciplined idempotency keys and careful state machines you get double charges or phantom captures. Getting this right across retries, webhooks and partial failures is the single most common place we see home-grown payment code quietly lose or duplicate money.
Reconciliation and the unaccounted penny
Your ledger, the PSP’s reports, the acquirer’s settlement files and the bank statement must all agree. They rarely do without deliberate engineering: fees, FX, rolling reserves, chargebacks, refunds and timing differences all pull the numbers apart. A platform that cannot reconcile to the penny is one that cannot tell you whether it has been paid.
PCI scope that shapes the whole architecture
The moment raw card data (a PAN), touches your systems, PCI DSS scope expands to everything that data can reach. Teams routinely underestimate this and end up with a compliance surface spanning half their estate. Containing scope through tokenisation, hosted fields and network segmentation is an architectural decision that has to be made early, not retrofitted.
Fraud and abuse the instant money moves
Card testing, account takeover, friendly fraud, refund abuse and collusion all arrive the day you start processing. Every control is a trade-off: too loose and you carry losses and chargebacks; too tight and you decline good customers and lose revenue. Tuning that balance needs real data, feedback loops and someone who understands both the fraud patterns and the revenue cost of a false decline.
Regulatory obligations that are load-bearing
PSD2 and SCA change how and when you can charge; safeguarding dictates how held funds are handled; AML imposes monitoring and reporting. These are not paperwork you satisfy once. They are runtime behaviour your software has to enforce on every transaction, and getting them wrong is a regulatory matter, not a backlog item.
What we build for payment platforms
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Payment gateway and processor integration
Robust integrations with PSPs and acquirers (card, wallets and alternative methods), built around idempotency, correct 3-D Secure and SCA handling, reliable webhook processing and sane retry semantics. We keep card data out of your scope by default, using tokenisation and hosted fields, and we handle the unglamorous edge cases that decide whether the integration is trustworthy.
Payment orchestration layers
A routing and abstraction layer over multiple PSPs and acquirers so you can route by cost, geography, method or health, fail over when a provider degrades, and retry declines intelligently. Done well this improves authorisation rates and resilience; done badly it adds a fragile single point of failure. We build it as the former and are candid about when you do not yet need one.
Ledgers and reconciliation systems
Double-entry ledgers as the authoritative record of money movement, plus automated reconciliation against PSP reports, acquirer settlement files and bank statements. We model fees, FX, reserves, refunds and chargebacks explicitly so that breaks surface immediately and are investigable, rather than being discovered weeks later in a spreadsheet.
Fraud and risk engines
Rules-based and model-assisted screening, velocity checks, device and behavioural signals, and case-management tooling for manual review. We instrument decisions so you can measure the actual cost of false positives and negatives, and we integrate specialist fraud vendors where they earn their keep rather than rebuilding what they already do well.
Subscription and recurring billing
Recurring billing that handles the genuinely hard parts: proration, trials, upgrades and downgrades, dunning and retry strategies for failed payments, SCA exemptions and mandates, and tax. Recurring revenue lives or dies on involuntary churn from failed renewals, so the retry and recovery logic gets real engineering attention.
Marketplace and split payments
Platforms that take payment and pay out to multiple parties (marketplaces, aggregators, platforms), with split settlement, connected accounts, payout scheduling, reserves and clear onward-liability handling. This is where safeguarding, flow-of-funds and regulatory treatment matter most, and where we are most insistent on using a licensed provider’s facilities rather than holding funds yourself.
Where we help
Checkout and gateway integration for a growing merchant
A business outgrows a basic plugin and needs a proper server-side integration: tokenised card capture, correct SCA and 3-D Secure flows, resilient webhook handling, and idempotent capture and refund logic. The goal is a checkout that maximises authorisation rates without ever double-charging, and that keeps the merchant out of heavy PCI scope.
Multi-provider orchestration to lift authorisation rates
A platform processing across regions wants to route transactions to the best-performing acquirer per market, retry soft declines on an alternate provider, and fail over automatically when one degrades. We build the routing, health-checking and observability so decisions are data-driven and every attempt is traceable end to end.
Ledger and reconciliation for finance you can trust
A scaling platform can no longer reconcile by hand. We introduce a double-entry ledger as the source of truth and automate reconciliation against PSP and bank data, so finance can close the books with confidence and any discrepancy is caught the day it happens rather than at month-end.
Fraud tooling to cut losses without killing conversion
A merchant seeing card testing and chargeback growth needs screening that blocks abuse while protecting good customers. We deploy velocity and risk rules, integrate a fraud vendor where warranted, and build review tooling and measurement so the team can tune the loss-versus-decline trade-off with evidence.
How we build for payments
We start from the flow of funds and the failure modes, not the UI. Before writing much code we map every state a transaction can be in, every place a retry or timeout can leave ambiguity, and every party the money touches on the way to settlement. In payments the state machine is the product; getting it wrong is expensive, so we get it right on paper and in tests before it goes near production money.
Idempotency and correctness are non-negotiable defaults, not later hardening. Every money-moving operation is idempotent by construction, every external call assumes it can be retried, and reconciliation is designed in from the first ledger entry rather than bolted on when the numbers stop tying out. We would rather spend the extra week early than spend a quarter chasing a penny-level break through production data.
We test the unhappy paths harder than the happy one, because that is where money is lost. We simulate timeouts, duplicate webhooks, out-of-order events, partial failures and provider outages, and we assert that the system neither loses nor duplicates a transaction under any of them. We build the observability (traces, ledgers, audit trails), that lets us prove after the fact exactly what happened to any given payment.
And we operate what we build. Payments does not tolerate a hand-off to a team that has never seen the failure modes, so the senior engineers who design the system stay close to it in production, on the alerts and in the incident when one comes. That is the only honest way to run software where the blast radius is money.
The regulatory landscape
PCI DSS is the dominant standard for anything that handles card data, and it is the one that most shapes your architecture. The controlling principle is simple: the less card data touches your systems, the smaller your compliance burden. We design to keep raw PANs out of scope entirely wherever possible (tokenisation, hosted fields and provider-side vaulting), so that your PCI surface is contained by design rather than sprawling across your estate. Where card data genuinely must be handled, segmentation and strict control of that boundary are the first architectural decisions, not the last.
PSD2 and Strong Customer Authentication govern how and when you can take a payment in Europe and the UK. SCA, 3-D Secure, and the exemptions that let you skip a challenge for low-risk or recurring transactions all have to be implemented correctly, because a mishandled authentication step is a declined sale or a liability shift you did not intend. Recurring and merchant-initiated transactions have their own mandate and exemption rules that the billing logic must respect on every renewal.
If your platform holds or moves customer funds in its own right, you are into payment-institution and e-money territory, with safeguarding obligations over how held funds are segregated and protected, and AML obligations to monitor, screen and report. This is precisely the ground where we advise most businesses not to build: carrying the licence and the safeguarding regime is a serious, ongoing regulatory undertaking. Our strong default is to integrate a licensed provider and let them hold the funds and the permission. We provide the engineering that sits on top; we are not a regulated firm and do not provide legal or compliance advice. You will want specialist counsel for the licensing questions, and we will build to whatever the resulting requirements are.
What payment platforms integrate with
At the top of the stack are the card networks (Visa, Mastercard and the rest), reached in practice through acquirers and processors rather than directly. Most platforms integrate a PSP or acquirer that abstracts the scheme connectivity, and the quality of that integration determines your authorisation rates, your latency and your exposure to their outages. We build these integrations to be resilient to the provider having a bad day, not just to work when everything is healthy.
Beyond cards, customers increasingly expect alternative payment methods, wallets like Apple Pay and Google Pay, buy-now-pay-later, and local methods that dominate specific markets, and account-to-account rails: Faster Payments and open banking in the UK, SEPA and SEPA Instant across the Eurozone, and their equivalents elsewhere. Each has its own settlement timing, refund behaviour and failure semantics, and a platform that treats them all as if they were cards will get the money movement wrong.
Then there is everything the payment data feeds: orchestration layers routing across multiple providers, fraud and risk vendors, the ledger and reconciliation systems, and the finance, ERP, tax and reporting tools downstream. Webhooks and asynchronous settlement mean these integrations are eventually consistent by nature, so we build them to tolerate retries, duplicates and out-of-order delivery as a matter of course, because in payments those are not edge cases, they are Tuesday.
Security in payments is existential
In most software a breach is serious; in payments it is existential. Card data is directly monetisable, so the systems that touch it are under constant, targeted attack, and the consequences of a compromise run from scheme fines to loss of your ability to process at all. Security here is not a checklist to satisfy an auditor: it is the difference between having a business and not.
The foundations are PCI compliance done properly, tokenisation so that raw card numbers live in a hardened vault rather than scattered through your services, and strong encryption in transit and at rest. We treat the cardholder-data boundary as the most tightly controlled part of the architecture: minimal, segmented, heavily logged and touched by as little code as possible. The best way to protect card data is to not hold it, and where we can arrange that, we do.
Fraud systems are part of security, not separate from it. Card testing, account takeover and abuse are attacks on the money, and the screening, velocity controls and monitoring that catch them belong alongside your other defences. We also build the audit trails and immutable logging that both security and compliance depend on, in a domain where you may have to prove exactly what happened to a specific payment months later, being able to reconstruct events precisely is itself a control.
What changes
Money that reconciles to the penny
A double-entry ledger and automated reconciliation mean your books tie out against PSP, acquirer and bank data, and any break is surfaced the day it happens, not discovered at month-end in a spreadsheet.
Payments that stay up under load
Idempotent operations, sane retries, graceful degradation and provider failover mean the checkout keeps working through peaks and through a provider’s bad day, without dropping or duplicating a single transaction.
Contained PCI scope and lower risk
Tokenisation, hosted fields and segmentation keep raw card data out of your systems, shrinking your compliance surface and cutting both the cost of PCI and the blast radius of any incident.
What we build for payment platforms
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for payment platforms?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in payment platforms choose us
We have built the hard parts
Idempotency, ledgers, reconciliation, orchestration and fraud tooling are not slideware to us. They are the specific things that go wrong in payment platforms, and the specific things we have built and operated. We know where home-grown payment code quietly loses money because we have been called in to find it.
We operate what we build
Senior engineers design the system and stay with it in production, on the alerts and in the incident. In a domain where the blast radius is money, we do not hand payments code to people who have never seen its failure modes.
We are honest about what not to build
We will tell you when you should integrate a licensed processor rather than build acquiring, when you do not yet need an orchestration layer, and when the right answer is a boring, proven provider. We provide engineering, not a licence, and we would rather lose the extra scope than sell you risk you should not carry.
Senior-led, no juniors learning on your money
Payments is the wrong place to train people. The people who scope your platform are the people who build it, experienced engineers who treat every money-moving line with the seriousness a mistake there deserves.
Related sectors
Part of Fintech & Financial Services. Adjacent sectors we also know.
Common questions
Should we build our own payment processing or integrate a provider like Stripe or Adyen?
For the large majority of businesses, integrate a licensed provider. Building your own acquiring, scheme connectivity and safeguarding regime is a multi-year, heavily regulated undertaking that carries a licence and obligations very few companies should take on. The right engineering work is almost always the integration, orchestration, ledger and fraud tooling on top of a provider, which is exactly what we build. We will be straight with you about where the line is for your specific situation.
How do you make sure customers are never double-charged?
Idempotency by construction. Every money-moving operation carries an idempotency key so that a retried request (whether from the network, the client or a webhook), resolves to the same single charge rather than a second one. We model the transaction state machine explicitly, handle timeouts as genuinely ambiguous outcomes to be reconciled rather than assumed, and test the duplicate-and-retry paths harder than the happy path, because that is where double charges actually come from.
What does PCI DSS mean for how our platform is built?
PCI scope expands to cover everything that raw card data can reach, so the single most important decision is to keep that data out of your systems wherever possible. We design around tokenisation and hosted fields so the sensitive card number lives in a provider’s hardened vault, not across your services. That contains your compliance surface, lowers the cost of PCI and shrinks the blast radius of any incident. Where card data genuinely must be handled, we segment and tightly control that boundary from the outset.
Can you help us reconcile payments and fix the numbers that do not tie out?
Yes. This is one of the most common reasons platforms come to us. We introduce a double-entry ledger as the authoritative record of money movement and automate reconciliation against PSP reports, acquirer settlement files and bank statements, modelling fees, FX, reserves, refunds and chargebacks explicitly. The result is that discrepancies surface the day they happen and are investigable, rather than accumulating into an untraceable gap that finance discovers weeks later.
Do you handle fraud prevention, and do you build it yourselves or use a vendor?
Both, depending on what earns its keep. We build the parts that belong close to your platform: velocity checks, risk rules, device and behavioural signals, and case-management tooling for manual review, and we integrate specialist fraud vendors where they already do a job better than we could rebuild. Crucially, we instrument the decisions so you can measure the real cost of false declines against fraud losses, and tune that trade-off with evidence rather than guesswork.
Building for payment platforms?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if payment platforms is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.