All BlueprintsFintech
Seller payout requests
Paying out the sellers on a marketplace, where what a seller can ask for, what is still clearing and what is already in flight are three different figures and the product can always say which is which. A request commits money without spending it, an administrator approves or refuses it exactly once, and a payout that fails afterwards puts the money back where it came from.
What you’ll build.
A payout system for a marketplace. Sellers see what they have earned and what is still clearing, prove who they are and where the money goes, and ask to be paid an amount that stops being available the moment they ask. An admin works a queue and approves or refuses each one once, with a reason. A failed payout puts the money back and says why.
What you’ll learn.
Each sprint is built around one skill. You show you have it in a pull request your team reviews, then explain it in a walkthrough.
Authentication
You can register and sign in a user, keep a request authenticated without asking for the password again, and explain where the credential lives in the browser and why there rather than somewhere else.
A ledger you can trust
You can record credits and debits and produce a balance that is the sum of them — and explain why the balance is not a column you update, and what happens when two movements land at once.
Verifying who a customer is
You can take a document from a user, hand it to a provider, and move the account between pending, verified and rejected as the answer arrives — and say what the user sees at each of those.
Paying money out
You can request a payout, hold the funds while it settles, and reflect success or failure on the balance — and show that pressing the button twice pays once.
Roles and permissions
You can give users different roles and have the server refuse what a role may not do — not merely hide the button — and show the refusal working against a request the interface never offered.
Going live
Somebody who has never met you can open a URL and use the product — and you can say what is different about the copy running there, where its secrets come from, and what you do when a release turns out to be wrong.
The roadmap. 8 sprints, 37 tasks.
Every sprint has a goal and a set of tasks. Open a sprint to see the tasks you will pick up.
Sellers and staff
Somebody can open a seller account and come back to it, and nobody can hand themselves the right to approve a payout.
4 tasks
- A seller can register and land signed in
- Signing back in survives a refresh and a night
- A seller can sign out on a machine that is not theirs
- Administrator accounts exist, and cannot be self-issued
What a seller has earned
A seller's balance is whatever their movements add up to, exact to the penny, with the part still clearing shown apart from the part they can have.
5 tasks
- A sale is recorded against a seller and becomes earnings
- A seller can see every movement their balance is made of
- Commission comes off, and the two halves add back up to the sale
- Recent sales are held, and the seller can see when they clear
- A balance is never a figure anybody typed
Verified enough to be paid
A seller says who they are and where their money should go, somebody checks it, and the product states in one place what makes a seller payable.
5 tasks
- A seller says who they are and where their money should go
- Waiting two days for an answer does not look like a fault
- Somebody records the answer, and a refusal says what to fix
- Changing where the money goes sends it back to be checked
- A seller can see whether they are ready to be paid, and what is missing
Asking to be paid
A seller asks for an amount they actually have, it stops being available the instant they ask, and two attempts at the same money cannot both succeed.
5 tasks
- A seller can ask to be paid an amount they actually have
- Money stops being available the instant it is asked for
- Two requests for the same money cannot both succeed
- A seller can see every request they have made and where it stands
- A seller can take back a request nobody has answered
Two sides of the queue
An administrator opens one screen and sees every request waiting. A seller sees only their own money, however they ask for it.
4 tasks
- An administrator sees every request waiting, oldest first
- One request opens with everything needed to answer it
- A seller cannot see another seller's money, however they ask
- A seller cannot reach the administrator's queue
Decided once
An administrator approves or refuses a request exactly once, an approval records the money as sent, and a refusal gives it back with a reason the seller can read.
5 tasks
- Approving a request records the money as sent
- Refusing a request gives the money back, with a reason
- One request gets one decision, whoever presses
- A seller learns the outcome without having to be watching
- An approved payout carries a reference somebody can quote
When it does not land
A payout recorded as sent can come back failed, and the money returns as a new movement with a reason the seller can act on.
5 tasks
- An administrator can record that a sent payout failed
- Failed money comes back without changing what was written
- The seller is told it did not arrive, in words they can act on
- A failure blamed on the account stops the next payout to it
- A seller's history reads as one event, and still adds up
Somewhere sellers can reach it
The product is on the internet at its own address, a bad release can be undone without losing a payout, and a failure reaches a person.
4 tasks
- The product runs at its own address, not on a laptop
- Every secret comes from outside the repository
- A release can be put back, and no payout is lost doing it
- Somebody finds out when money stops clearing
Read before you build. The best engineers do.
Senior engineers read the docs before they touch the code. Every Blueprint comes with short documents on the product and its world, the kind a team hands a new hire. Read them well and you ask sharper questions and walk into every review prepared.
What you are building
The product, the two people who use it, and why the interesting part is the arithmetic rather than the workflow.
Four numbers, not one
Domain you will not have: what earned, clearing, in flight and paid out actually mean, why marketplaces hold money back, and the vocabulary the rest of the road map uses.
More fintech Blueprints.
Shared expense splitter
A group logs what each person paid, the app works out who owes whom, and settling up clears it. No money moves through the product: it keeps the record, and the record has to balance to the penny for every split, correction and settlement the group throws at it.
Budget and spending tracker
A budget for one person, kept honestly a month at a time. Spending lands in categories, every figure on the screen is the sum of the entries behind it, and a month ends: it closes, it stops moving, and what is left over or overspent follows the person into the next one by a rule they can read.
Freelance invoicing
Invoicing for one freelancer: build an invoice whose total survives being added up by hand, send it to a client who never signs in, settle it with the money that actually arrived, and correct a mistake without quietly rewriting a document somebody has already acted on.
Build seller payout requests.
Start your free week. Adaeze runs your kickoff, and Lars reviews every pull request.