A payment product is judged on the days it goes wrong. Idempotency, reconciliation, and a clear audit trail are the whole job.
Payments software has an unusual property: the happy path is easy and almost irrelevant. What determines whether a platform is trustworthy is what happens when a request times out after the charge succeeded, when a webhook arrives twice, or when two systems disagree about a balance.
We build these products around those cases first. Every money-moving operation is idempotent, so a retry cannot double-charge. Every integration has a reconciliation job that detects disagreement rather than waiting for a customer to report it. Every state change leaves an audit trail you can hand to a regulator.
On PCI DSS, the first move is always scope reduction. The cheapest compliance work is the work you engineer your way out of needing.
Gateways, wallets, and the onboarding flows that scale them.
Servicing, repayment, and borrower-facing tooling.
Automated detection of the disagreements that cost real money.
Scope reduction first, then the controls the remainder requires.
Stripe and others, with idempotency and replay handled properly.
Dashboards that show failures, not just volume.
Identity and sanctions checks recorded as decisions you can replay.
Wallets, transfers, and cash-in and cash-out on the phone.
Scored inline, with every decline explainable after the fact.
The work is integration and correctness. A charge, a transfer or a payout crosses systems you do not control, each with its own retry semantics and its own opinion about when a thing is final. The product is judged on whether those opinions can be reconciled without a human reading a spreadsheet.
A loan is a payments problem with a memory. Interest accrues, schedules change, payments arrive early, late or partially, and the balance has to stay defensible across every one of those events. Collections adds a second constraint, because contact itself is regulated.
Most platforms in this segment eventually do both. A lending product bolted onto a payments ledger inherits the wrong assumptions about how long a balance lives, and the correction lands years later in a reconciliation nobody can close.
The estimate on a payments build is driven by integration surface, not by screen count. Two products with identical interfaces can differ by a factor of three in effort because one of them settles through a single processor and the other reconciles four systems that each believe they hold the truth.
So the first pass is an inventory. We list every system that touches money or identity, establish which of them is authoritative for each fact, and find where they can disagree. That list is what gets estimated in story points, and it is why the number holds.
The integration inventory
The order matters. Correctness decisions taken after a flow ships are audits of every write path you already wrote.
Step 01
Every money-touching system is listed, the authoritative source for each fact is named, and the disagreements are found on paper. The scope comes out of that list and is priced before anyone builds.
Step 02
The money model is decided first: what a transaction is, what states it can hold, and which key makes an operation safe to repeat. Idempotency is defined at the point each operation is defined, because retrofitting it means auditing every write path already shipped.
Step 03
Flows are engineered so card data lands in as few systems as possible, normally by pushing capture to the processor. What remains in scope is then controlled deliberately rather than inherited by accident.
Step 04
Processors, rails and vendors are wired with duplicate delivery, out of order events and missing callbacks treated as normal traffic rather than incidents. Every inbound event is replayable against the ledger.
Step 05
Automated jobs compare the ledger against each external system on a schedule and raise the differences. Dashboards report declines, timeouts and unreconciled items, because volume alone hides all three.
Step 06
Controls and evidence are packaged for whoever signs off, and the documentation is produced from the work rather than reconstructed afterwards. IP assignment happens on full payment, automatically and in the contract.
Figures published by the clients themselves.
Today's user experience is completely different than it was in the past. Now users are presented with only the actions and flows that are directly relevant to them.
Four failures account for most of the money lost in this segment, and none of them are exotic. They are the cases that never make it into a demo, which is exactly why they are still there at launch.
Machine learning is routine in this segment, and it is worth being specific about where it pays. Fraud scoring, credit decisioning, and collections prioritization are the three places a model beats a rule set, because each is a ranking problem over data you already hold.
The constraint is that a model here produces decisions about people, and those decisions have to be explainable after the fact. An applicant declined for credit is owed a reason, and a disputed transaction is reviewed by someone who was not in the room. So we store the features and the score alongside the decision, version the model that produced it, and keep a rules path that can override it. A score that cannot be reconstructed six months later is a liability rather than an asset.
We also say plainly when a model is not the answer. Most fraud caught in the first year of a new platform is caught by velocity limits and a blocklist, and a model trained on a few thousand transactions mostly learns the shape of your test data.
A first payments or lending product, where the pressing risk is building the wrong correctness model and discovering it in production.
An existing platform that has to scale, integrate or be modernized without pausing the money moving through it.
A build that has stalled or lost its team. Payix arrived this way, and the first work was architectural rather than cosmetic.
Scoping only: the integration inventory, the correctness model and a priced backlog, whether or not we build it.
Payment and lending builds are delivered by AI Pods against a committed scope, estimated in story points and priced before work begins. The estimate comes out of an integration inventory, because processor and ledger surface is what actually drives effort here.
Compliance work is the exception and is never story-point priced. Audit and attestation are scoped as a retainer or a fixed fee, because the deliverable is an opinion rather than a feature.
The integration inventory is what sets the estimate here. These three case studies show what that inventory turned into.
Case study: a rigid payment platform where standing up a client took months, rebuilt so it does not
Case study: a gateway rebuild that moved daily transactions from 4,000 to 120,000
Case study: corporate credit for Colombian SMEs, built from an idea and acquired by Bold
The capability this segment leans on most, including the reconciliation that catches drift before a customer reports it
In 30 minutes, we will show you what a Pod would ship first and how we would price it.
