Skip to content

Fintech · MVP

Splitta

Instalments for online stores: buyer checks, a payment schedule and refunds — on real payments from day one.

Role
Product design, frontend, backend, infrastructure
Timeline
7 weeks
Stack
Next.js · Node.js · Docker

What changed

46 days
from the first meeting to the first payment by an actual buyer. The date was not the project’s to choose: the store’s season opened on day forty-nine.
210 applications
over the pilot’s first six weeks, 138 of them approved. That is what the idea was tested on, rather than a deck.
16 refunds
one in nine of the plans taken out, with the schedule rebuilding itself. This is the part that was nearly pushed to version two.
11 minutes
median from application to decision during working hours. An application at night waited for the morning: a person decides, not a rule.

The economics of the instalment plans stayed exactly where they were, and could not have moved: who gets approved, over what term and on what conditions is the client’s rulebook, and the code carries a decision out rather than writing it. Nor did seven weeks prove anything about the market — six weeks at one store answers whether the flow holds and whether the money moves correctly, not whether many people want this. What the speed cost is listed above: review by hand, no automated tests outside the money paths, one payment method. That is work somebody will do, not work that turned out to be unnecessary.

Before

The product was built from nothing while onboarding with the payment provider ran alongside it: without live keys an instalment plan is a slide deck, and the date those keys arrive is not ours to set. The application went to the provider on day three of the project, ahead of the first line of code. Sandbox credentials came on day nine, live keys on day thirty-seven — twelve days before the date everything had to work.

  • The company had been lending in instalments for years, but only in partner shops, where the decision is made by someone with the buyer standing in front of them. There had never been an online application, and so there was no history of them either.
  • Four online stores had said the idea sounded interesting and asked to see it working. There was nothing to show: the flow lived on slides, and nobody hands over a checkout to slides.
  • The date was not the project’s to pick. The partner store would let instalments into its high season, forty-nine days away; the window after that opened six months later, and until then the idea would simply sit.

What we built

  • The buyer flow: application, review, schedule and first payment — nine screens on our domain, with the store handing the buyer over by link and getting one webhook back.

  • A payment layer behind one interface: charge, cancel, refund and retry with idempotency keys — the provider changes by configuration rather than by rewrite.

  • An admin panel for manual review: for the pilot the client’s own staff open each application — decision, note, and a refund that rebuilds the schedule, all in one place.

Outcome

The service reached production inside seven weeks: the first payment by an actual buyer went through on day forty-six, three days before the season the deadline had been set by. And there was something to test — not a demo but the whole path of the money: the application, a bank decline, a retry, a refund with the schedule rebuilt. The speed was paid for with review by hand, one payment method and a single store in the pilot; all of it was named as the price up front rather than found after launch.

The client

A consumer finance company that has been writing instalment contracts for years — but only across the counter, in partner shops, where an assistant sits opposite the buyer with the paperwork on the desk between them. Online it had nothing: not one application, no history of applications, not a single store connected.

In a shop a decision takes an assistant twenty minutes or so, and half the questions can be asked out loud. In a browser all that is left of the buyer is a form, a card and a few seconds of patience. So what needed testing was not the company’s ability to price risk. It was two things outside the company’s control: whether a buyer would reach the end of the flow, and whether a store would let a new payment method near its checkout.

The brief

What the client asked for
Do it the way the big lenders do: the buyer taps in checkout and a second later sees a decision and a schedule. Version one was meant to include automated scoring, an account area for buyers, and a partner area so that stores could sign themselves up.
What the brief turned into
There was nothing to build scoring on. An offline decision rests on what an assistant can see across a desk, and online applications did not exist yet, so any threshold in version one would have been invented at the client’s expense. The expensive part sat somewhere else: refunds. Roughly one order in nine comes back in this category, and a refund against an instalment plan is not a cancelled payment — it is a live schedule that has to be rebuilt. Hence a different brief: seven weeks does not buy a product for a market, it buys one flow end to end — one store, real money, and the branches where things go wrong included. The credit decision is made by a person, and that went into the plan rather than being discovered in week two.

Why the obvious route was closed

Seven weeks was not speed. It was a timetable set by decisions made elsewhere: four conditions came from outside and would not move, and two we took on ourselves and agreed before the work started.

The season date
The store would open instalments to buyers on a fixed date and no other: out of season its traffic runs at about a third, and a pilot on that would answer nothing for months. Forty-nine days was the entire budget, and there was nothing to borrow from the end, because the end was not ours.
The provider’s live keys
Compliance review runs on the provider’s clock, not on a project plan. A sandbox resembles production exactly as far as the provider promised, and it parts company on declines, retries and refunds, which is where the risk in this project actually sits.
Two days of someone else’s developer
The store could spare its developer for two days, with its busiest season about to start. Anything larger than a link and a webhook would not have been integrated in time, however good it looked on our diagram.
One order in nine comes back
In this category a return is routine rather than an edge case. That put the most expensive logic in the project into version one and left the cheap parts waiting their turn.
Real money, not a sandbox
This one was ours. A pilot on test payments would have proved that our code runs, not that the product works: a bank decline, a retry, a partial refund, a card that expires between two instalments — none of that exists anywhere but on real money. The price is that nothing can be shipped half-working to see what happens.
A person makes the decision
Also ours, also agreed up front: each application is opened by one of the client’s staff. One person gets through around fifty in a shift — three minutes each, plus a call wherever something does not add up. The pilot ran at five, and the limit we hit was not the count but the clock: an application filed at night waited for the morning. With a second and a third store that wait would have reached a noticeable share of buyers, so the pilot was capped at one store from the start.

How the work ran

  1. 01

    Discovery and the flow

    1 week

    Five days went on the path of the money: what happens between a buyer choosing instalments and the store receiving its transfer, and every branch where something else happens instead — a decline, a cancellation, a charge that fails, a return. Two decisions came out of that week and shaped the other six: no scoring in version one, and refunds stay in it. The provider application went out on day three, since it was going to wait longer than the code would.

  2. 02

    The payment layer and the schedule

    1.5 weeks

    Charge, cancel, refund and retry behind a single interface, so the provider stayed a replaceable part rather than a foundation. The schedule arithmetic belongs here too: integers in minor units, the rounding remainder pushed into the first instalment, a rebuild after a partial refund. This is the only part of the project that got tests, and the first that ran against the sandbox.

  3. 03

    Application, review, admin

    1.5 weeks

    Nine buyer-facing screens on our domain, and an admin panel where one of the client’s staff opens the application: the form, the result of binding the card, whatever the company already knows about this buyer, then a decision and a note against it. No design system was started: one flow was drawn end to end and components were built as they were needed. On four people and seven weeks a component library never pays for itself.

  4. 04

    Refunds and rebuilding the schedule

    1 week

    An expensive week, planned to be expensive. A full refund closes the schedule and returns what has been paid; a partial one reduces the balance and rebuilds the instalments still to come without touching the ones already taken. The difficulty is not the formula: a return is started by the store, the money moves through the provider, and the schedule sits on our side — three parties have to arrive at one figure, and they can arrive in any order.

  5. 05

    Production, live keys, first payments

    2 weeks

    Infrastructure was not saved for the end: the same image that ran on staging had been running since week one. Live keys arrived on day thirty-seven, and moving onto them took a configuration change and a restart. Then nine days of our own cards and small amounts: a charge, a bank decline, a retry, a refund. The first payment by an actual buyer went through on day forty-six, three days before the season.

Technical decisions

The stack answers three facts about this project rather than the problem in general: a team of four covering two interfaces, money arithmetic that has to be identical in three places, and a key delivery date set outside the project.

  • The provider as a replaceable part

    Charging, cancelling, refunding and reading a payment’s status sit behind one interface, and the rest of the code knows four methods and one set of errors. There are two implementations: the live provider, and a second one taken as far as its sandbox. The second was not a paper fallback, it was the test of the interface — with a single implementation, an interface always ends up shaped like that implementation. The point of no return was set at day forty: no keys, and we move, four days out of the nine that would be left. The keys came on day thirty-seven. Whether the move would have worked, we do not know.

  • Integers for money, a schedule stored as rows

    No amount is ever a floating-point number: minor units, integers. The schedule is calculated once, when the plan is taken out, and written to the database as individual instalments with dates, rather than as a formula re-evaluated on every screen. The rounding remainder goes into the first instalment instead of being spread across all of them, so the schedule equals the order total exactly, and one comparison settles it with no reasoning about rounding.

  • Idempotency keys and an application log

    Every request to the provider carries a key derived from the payment’s identifier, so a retry after a timeout cannot produce a second charge. Every state change of an application is a row in a log: who, when, what the provider returned, what it became. On real money the question of what happened to a given payment gets asked the same day, and answering it by opening a support ticket with the provider means answering it tomorrow.

  • A link and a webhook instead of an SDK

    The store’s entire integration is a signed link carrying the order and its total, and one webhook back saying whether the plan was taken out. It never touches keys or schedules. That was not elegance, it was the two days of developer time the store had. The side effect turned out to matter more than the intent: because the flow runs on our side, it is the same at every store and can be changed without waiting for their release. Next.js is here for precisely that — nine buyer screens and the admin panel as one application, one deployment, one set of forms.

  • One image, two configurations

    Staging and production are the same image and differ only in environment variables, provider keys among them. That is why the day the live keys arrived was not an event: a configuration change and a restart, instead of a branch, a release and a second round of testing. Docker is not here for scale — the pilot runs one container and one database — but so that a date set outside the project does not turn into a risk inside it.

What stayed outside the scope

Below is the list of what version one does not have. It was written before launch rather than after: every line has a reason and a price.

  • An automated credit decision. No rule can be written before the first full payment cycle closes: until a schedule has run to its end, there is no way of knowing who was approved wrongly. The first two hundred applications and their outcomes are material, not an answer.

  • Automated tests outside the money paths. The schedule, refunds and retries are covered; the admin panel and the side screens were checked by hand. The price is known: of the four defects found in the first two weeks after launch, three were in the admin panel.

  • Store onboarding. The second and third stores are being connected by us, by hand, about a day each. A partner area where a store connects itself was not built: adding it before the flow settles would freeze an interface around something that is still moving.

  • Arrears. Reminders are automated; everything past them is a person working to the client’s rules, drafted by their own lawyer. None of that was put into code, deliberately.

  • Payment methods. Version one binds a single card for the whole schedule. Every method after that is another refund branch, and refunds were already the most expensive thing here.

In progress: the second store, and rules that would approve the simplest applications automatically, drawn from the first months of data. Anything more complicated than a rule is still opened by a person.

More projects

All projects

Contact

Send a description of the task

A reply with the scope, the timeline and a budget estimate comes within 24 hours.

Get an estimate

The first call is 30 minutes, with no commitment on your side.