Got a project?

Get in touch
All work

Confidential — consumer lending

One form. Seven lenders. Four seconds.

A single loan application that fans out to seven separate lender APIs, normalises seven different sets of nonsense, and returns a ranked list of real offers before the applicant loses interest.

Client
Confidential — consumer lending
Year
2025
Role
Sole developer — architecture, integration, error handling, monitoring
7
Lender APIs integrated
~4s
Median full-panel response
99.95%
Uptime since launch

Context

A consumer lending business was sending the same loan application to seven providers by hand. A staff member re-keyed the applicant’s details into seven different portals, waited, and phoned the customer back — usually the next day, sometimes the day after.

By then the customer had applied somewhere else.

The problem

Every lender’s API was different, and all of them were bad in their own particular way.

Two were clean REST with sane JSON. One was SOAP, and its WSDL didn’t match what the endpoint actually returned. One accepted a POST and then delivered its decision by webhook forty seconds later. One rate-limited at a level nobody had documented. Two returned HTTP 200 on failure with the actual error buried in a string field.

None of them agreed on what an ID number field was called, how income should be formatted, or what “approved” meant.

What I did

I built a normalisation layer first, before touching a single integration. One internal application schema, and seven adapters that translate to and from it. Adding an eighth lender is now a new adapter class and a config entry — about a day’s work, not another integration project.

Each lender call runs in its own queued job, so one slow provider can’t hold up the other six. Anything asynchronous is reconciled by webhook against an idempotency key, which means a duplicate callback is a no-op rather than a duplicate loan offer.

The part that mattered most was the failure handling. Every request and response is logged with a correlation ID. When a lender changes their contract without telling anyone — which happened twice during the build, and has happened since — the alert names the lender, the field, and the payload that broke. Debugging is reading one log line, not reproducing a customer’s application by hand.

I also said no to two things the brief asked for: a scoring engine that would have duplicated what the lenders already do, and a caching layer for decisions, which would have been a compliance problem waiting to happen.

The result

One form, submitted once. The full panel of seven lenders answers in about four seconds, and the applicant sees ranked, real offers on the same page they applied on.

The re-keying job no longer exists. The system has run at 99.95% uptime since launch, and the two lender contract changes that broke it were diagnosed and patched inside an hour each — because the logging was built before the features.

Got something like this that needs building?

A few lines about what you’re trying to build or fix is enough. It lands in my inbox and I reply within the business hour — honestly, including whether I’m the right person. If I’m not, I’ll say so and point you at someone who is.

I reply to every enquiry within one business hour.

Prefer email? support@yourdesign.co.za· (+27) 079 177 1970

Next case study — Will management platform — later acquired →