# Payments and Lending Software Development

> Payment platforms, lending products and collections tooling. Idempotent by design, PCI-aware, and built to reconcile.

Source: https://www.koombea.com/industries/payments-and-lending/

---

A payment product is judged on the days it goes wrong. Idempotency, reconciliation, and a clear audit trail are the whole job.


## What makes this different

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.

- Idempotent money movement, so a retry is never a second charge
- Reconciliation that detects drift between systems automatically
- PCI DSS scope reduced by design before controls are added
- Audit trails on every state change, built for review

## What we build here

- **Payment platforms**: Gateways, wallets, and the onboarding flows that scale them.
- **Lending and collections**: Servicing, repayment, and borrower-facing tooling.
- **Reconciliation**: Automated detection of the disagreements that cost real money.
- **PCI DSS**: Scope reduction first, then the controls the remainder requires.
- **Processor integration**: Stripe and others, with idempotency and replay handled properly.
- **Operational visibility**: Dashboards that show failures, not just volume.
- **Onboarding, KYC and AML**: Identity and sanctions checks recorded as decisions you can replay.
- **Mobile money movement**: Wallets, transfers, and cash-in and cash-out on the phone.
- **Fraud and risk scoring**: Scored inline, with every decline explainable after the fact.

## Payments and lending are not the same build

### Payments — Money moves in seconds and has to be right the first time.

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.

- Gateways, checkout flows and one-click purchase paths
- Digital wallets, stored balances, cash-in and cash-out
- Domestic and cross-border transfers, with real-time status
- Merchant and reseller onboarding, including the approval workflow
- Settlement, payout and chargeback handling
- Business intelligence on volume, decline reasons and failure rates
### Lending and collections — The balance is alive for years, and every touch of it is regulated.

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.

- Origination and application flows, with decisioning kept auditable
- Servicing, amortisation and repayment scheduling
- Borrower self-service: balances, payoffs and payment arrangements
- Collections workflow, contact rules and promise-to-pay tracking
- Payment plan changes that reconcile against the original schedule
- Statements and disclosures generated from the ledger, not restated

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.


## What we inventory before quoting

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

- Processors and acquirers: Which ones, in which markets, and what each considers final
- The ledger: Whether one exists, whether it is authoritative, and who writes to it
- Bank rails and payout paths: ACH, wires, local rails, and the settlement windows each imposes
- Identity, KYC and sanctions vendors: Where the decision is made and whether it can be replayed later
- Webhooks and event delivery: Every endpoint that can fire twice, out of order, or not at all
- Card data touchpoints: Every place card data currently lands, which sets your PCI scope
- Reporting and finance systems: What finance reconciles against today, and how often it disagrees


## How a payments build reaches production

The order matters. Correctness decisions taken after a flow ships are audits of every write path you already wrote.

Inventory and scope: 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. (Integration inventory, story point estimate, committed scope)
Ledger and idempotency design: 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. (Money model, idempotency keys, state machine)
PCI scope reduction: 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. (Tokenisation, hosted capture, scope boundary)
Integration and replay: 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. (Webhooks, retries, event replay)
Reconciliation and observability: 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. (Reconciliation jobs, alerting, failure dashboards)
Attestation and handover: 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. (Written security attestation, runbooks, IP assignment)

## Proof from this segment

Figures published by the clients themselves.

- Daily transactions at Paymentez: Up from 4,000, after the gateway and its flows were rebuilt
- LAN house resellers in one year: Growth the previous flows could not be provisioned fast enough to serve
- Conversion increase in six months: From showing each user only the actions relevant to them

"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."

Miguel Ramirez, CPO, Paymentez


## Where payment projects usually go wrong

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.

- A retry path that was never tested under a timeout, so a customer is charged twice and support finds out before engineering does
- Webhooks treated as reliable, so a duplicate delivery moves money a second time and an outage silently drops a settlement
- Reconciliation deferred to a later phase, which means the first disagreement between systems is discovered by a customer
- PCI scope accepted as given rather than engineered down, so the compliance bill is set before the architecture is

## Where a model earns its place

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.

- Fraud and chargeback scoring, with the features and score kept alongside the decision
- Credit and affordability decisioning, versioned so any decline can be reconstructed
- Collections prioritization, ranking accounts by likely recovery rather than by age
- Anomaly detection on reconciliation breaks, surfacing drift before finance finds it

## How teams arrive here

- **A new product**: A first payments or lending product, where the pressing risk is building the wrong correctness model and discovering it in production.
- **An enterprise platform**: An existing platform that has to scale, integrate or be modernized without pausing the money moving through it.
- **A rescue**: A build that has stalled or lost its team. Payix arrived this way, and the first work was architectural rather than cosmetic.
- **A plan before a build**: Scoping only: the integration inventory, the correctness model and a priced backlog, whether or not we build it.

## How fintech work is scoped and priced

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.


## Partnerships and certifications


## Questions worth asking

### What does fintech software development actually involve?

In practice it is integration and correctness work far more than interface work. Processor and ledger integration, idempotent money movement, reconciliation between systems that will disagree, and an audit trail a regulator can read. The screens are the visible part and the smallest part of the estimate.
### Can you reduce our PCI DSS scope?

Usually, and it is the first thing we look at. Scope reduction means engineering the flow so that card data never touches systems you would otherwise have to certify, normally by pushing capture to the processor. The cheapest compliance work is the work you engineer your way out of needing.
### How do you keep a retry from double-charging?

Every money-moving operation carries an idempotency key, so a repeated request resolves to the same result rather than a second charge. That has to be designed in at the point the operation is defined. Retrofitting it means auditing every write path you already shipped.
### Do you work with our existing processor?

Yes. We are a Stripe Verified Partner and have built against Stripe extensively, but the pattern is processor-agnostic and most platforms in this segment run more than one. What matters is that replay, settlement and reconciliation are handled the same way regardless of which one is behind the call.
### Can you build lending and collections, not just payments?

Yes. Servicing, repayment scheduling, borrower-facing tooling and collections workflow are in scope, and Payix is a case study in exactly that. The correctness constraints are the same ones payments has, with a longer-lived balance to keep accurate.
### Do you build mobile banking and wallet products?

Yes, and the hard part is rarely the app. A wallet is a stored balance, which means it is a ledger with a customer attached, so the questions are the same ones a payments platform answers: what makes a balance authoritative, what happens when a top-up succeeds after the client gave up, and how the balance reconciles against the rail behind it.
### Can you handle KYC, AML and sanctions screening?

Yes, as an integration and an evidence problem rather than as a policy one. Your compliance team or counsel sets the policy. We wire the vendors, record each check as a decision with its inputs and its outcome, and make those decisions replayable, because a screening result you cannot reconstruct is not evidence when someone asks.
### Do you use machine learning for fraud or credit decisions?

Where the data supports it. Fraud scoring, credit decisioning and collections prioritization are the three cases that reward a model. We keep the features and the score with the decision and version the model behind it, so any outcome can be reconstructed and explained later. On a new platform with thin history we start with velocity limits and rules, because a model trained on a few thousand transactions mostly learns your test data.
### What about crypto and digital assets?

We have built in this space, and the honest framing is that custody and key management are the deciding constraints rather than the trading interface. If you hold customer assets, the risk model is closer to a bank's than to a payments gateway's. We will tell you during scoping which parts of that we would take on and which belong with a specialist custodian.
### How long does a payments build take?

It depends almost entirely on the integration inventory, which is why we build that first and quote from it rather than from a category average. A gateway settling through one processor and a platform reconciling four systems look similar as products and differ by a factor of three in effort.

## Where to go next

The integration inventory is what sets the estimate here. These three case studies show what that inventory turned into.

- Payix: Case study: a rigid payment platform where standing up a client took months, rebuilt so it does not
- Paymentez: Case study: a gateway rebuild that moved daily transactions from 4,000 to 120,000
- Tuily: Case study: corporate credit for Colombian SMEs, built from an idea and acquired by Bold
- Integrations and Data: The capability this segment leans on most, including the reconciliation that catches drift before a customer reports it