The money already had a plan
Building Vendor Wallet at Chowdeck made me think about what happens next, and how we could help vendors keep track of the plans they already had for their money.
A vendor makes sales on Chowdeck. We settle their earnings into their bank account. The money lands, and the payout is complete.
But the vendor still has a business to run.
Some of that money will go towards operating expenses. Some might go towards advertising. There are decisions to make, payments to send, and transactions someone will eventually need to account for.
I kept coming back to that part of the journey.
Chowdeck was already helping vendors make money and manage their businesses. It felt reasonable that they should be able to use that money from within the product too.
That was the question we built Vendor Wallet around.
I made an interactive companion to the article here
Following the money a little further
I was coming into this with two experiences that shaped how I thought about it.
At Flutterwave, we’d brought bank transfers into the merchant dashboard so businesses could see their payments in one place. At Mira, we’d built tools for the everyday work of running restaurants.
Both were relevant here. There was the money itself, and there was the business that needed to do something with it.
A wallet could let a vendor receive money, hold it, and transfer it whenever they wanted. That was a useful starting point.
But I was interested in what happened before the transfer.
Think about the balance in a business account. It gives you one number, even when the person running the business has already divided that money up in their head.
This amount is for advertising. That amount is for operating expenses.
The account adds everything together. You’re the one keeping track of what each part is supposed to do.
I wanted us to make that easier.
Advertising was one reason to separate money. We could have given it a dedicated wallet. But then, what happened when a vendor wanted to set money aside for another purpose? Would that need its own wallet experience too?
I wanted a structure we could keep using as those needs grew.
That became Pockets.
Giving the money a purpose
The idea was fairly simple.
A vendor could create a pocket inside their wallet, name it, and put money there for a particular purpose. Each pocket would have its own balance and a separate view of the money moving through it.
So if you set money aside for advertising, you could come back and see what had happened to that money without picking through transactions for everything else your business was doing.
The name was only one part of it.
The separation needed to carry through the balance, transaction history, and statement. Otherwise, the vendor would still have to reconstruct the story themselves.
I wanted someone to open a pocket and understand it.
How much is here? What came in? What went out?
These are ordinary questions. The product should be able to answer them.
For the first release, I specified a limit of three pockets. Enough room to separate money for different purposes while keeping the wallet easy to follow.
Vendors chose the names and what each pocket was for. Direct connections to advertising campaigns were outside that first release. A vendor could set money aside for advertising, but Pockets needed to be useful for other things too.
The details you notice when it’s your money
I believe transparency does a lot of the work of building trust in a financial product.
Reliability matters. Consistency matters. But people also want to understand how their money moves.
That showed up in details across the wallet.
Take transfer fees.
Before a vendor confirms a transfer, they should be able to see what will leave their wallet and what the recipient will receive. They still have a decision to make at that point. The breakdown belongs there.
Finding out afterwards is a frustrating way to learn how a product works.
Transaction history raised similar questions for me during testing.
Who sent this money? Who initiated the transfer? Is there a reference I can use if I need to follow it up?
Someone running a business will eventually ask those questions. I wanted the answers close to the transaction, where they would look for them.
With Pockets, there was another question to answer: what had happened to the money they’d set aside for a particular purpose?
That intention needed to remain visible as the money moved.
Getting it into vendors’ hands
The initial Vendor Wallet went into a limited rollout in March 2026.
By 1 April, vendors were receiving payouts into their wallets and transferring money out.
There’s something useful about seeing a product handle real money. It brings all those decisions into focus. The balance, the fees, the transaction details—someone is now relying on them to run their business.
The wider Nigeria launch followed in April.
Existing vendors could choose to receive their settlements in the wallet or continue receiving them in their bank accounts.
For activation, I wanted us to focus on vendors actually receiving their earnings in the wallet. Opening a wallet was only the beginning. It became useful when a vendor could bring their money in and use it to run their business.
Pockets took that a little further. Once the money arrived, a vendor could set some aside for advertising or operating expenses and follow it separately. The balance, transaction history, and statement needed to make that easy to understand when they came back.
We launched Pockets on the dashboard and mobile on 8 June, towards the end of my first year at Chowdeck. It brought us back to the question that started this work: what happens after the vendor gets paid?
By then, the money usually already has somewhere to go. The person running the business knows what they need it for. I wanted the wallet to help them carry that intention through, from setting the money aside to understanding how it was spent.
The money already had a plan
Building Vendor Wallet at Chowdeck made me think about what happens next, and how we could help vendors keep track of the plans they already had for their money.
A vendor makes sales on Chowdeck. We settle their earnings into their bank account. The money lands, and the payout is complete.
But the vendor still has a business to run.
Some of that money will go towards operating expenses. Some might go towards advertising. There are decisions to make, payments to send, and transactions someone will eventually need to account for.
I kept coming back to that part of the journey.
Chowdeck was already helping vendors make money and manage their businesses. It felt reasonable that they should be able to use that money from within the product too.
That was the question we built Vendor Wallet around.
I made an interactive companion to the article here
Following the money a little further
I was coming into this with two experiences that shaped how I thought about it.
At Flutterwave, we’d brought bank transfers into the merchant dashboard so businesses could see their payments in one place. At Mira, we’d built tools for the everyday work of running restaurants.
Both were relevant here. There was the money itself, and there was the business that needed to do something with it.
A wallet could let a vendor receive money, hold it, and transfer it whenever they wanted. That was a useful starting point.
But I was interested in what happened before the transfer.
Think about the balance in a business account. It gives you one number, even when the person running the business has already divided that money up in their head.
This amount is for advertising. That amount is for operating expenses.
The account adds everything together. You’re the one keeping track of what each part is supposed to do.
I wanted us to make that easier.
Advertising was one reason to separate money. We could have given it a dedicated wallet. But then, what happened when a vendor wanted to set money aside for another purpose? Would that need its own wallet experience too?
I wanted a structure we could keep using as those needs grew.
That became Pockets.
Giving the money a purpose
The idea was fairly simple.
A vendor could create a pocket inside their wallet, name it, and put money there for a particular purpose. Each pocket would have its own balance and a separate view of the money moving through it.
So if you set money aside for advertising, you could come back and see what had happened to that money without picking through transactions for everything else your business was doing.
The name was only one part of it.
The separation needed to carry through the balance, transaction history, and statement. Otherwise, the vendor would still have to reconstruct the story themselves.
I wanted someone to open a pocket and understand it.
How much is here? What came in? What went out?
These are ordinary questions. The product should be able to answer them.
For the first release, I specified a limit of three pockets. Enough room to separate money for different purposes while keeping the wallet easy to follow.
Vendors chose the names and what each pocket was for. Direct connections to advertising campaigns were outside that first release. A vendor could set money aside for advertising, but Pockets needed to be useful for other things too.
The details you notice when it’s your money
I believe transparency does a lot of the work of building trust in a financial product.
Reliability matters. Consistency matters. But people also want to understand how their money moves.
That showed up in details across the wallet.
Take transfer fees.
Before a vendor confirms a transfer, they should be able to see what will leave their wallet and what the recipient will receive. They still have a decision to make at that point. The breakdown belongs there.
Finding out afterwards is a frustrating way to learn how a product works.
Transaction history raised similar questions for me during testing.
Who sent this money? Who initiated the transfer? Is there a reference I can use if I need to follow it up?
Someone running a business will eventually ask those questions. I wanted the answers close to the transaction, where they would look for them.
With Pockets, there was another question to answer: what had happened to the money they’d set aside for a particular purpose?
That intention needed to remain visible as the money moved.
Getting it into vendors’ hands
The initial Vendor Wallet went into a limited rollout in March 2026.
By 1 April, vendors were receiving payouts into their wallets and transferring money out.
There’s something useful about seeing a product handle real money. It brings all those decisions into focus. The balance, the fees, the transaction details—someone is now relying on them to run their business.
The wider Nigeria launch followed in April.
Existing vendors could choose to receive their settlements in the wallet or continue receiving them in their bank accounts.
For activation, I wanted us to focus on vendors actually receiving their earnings in the wallet. Opening a wallet was only the beginning. It became useful when a vendor could bring their money in and use it to run their business.
Pockets took that a little further. Once the money arrived, a vendor could set some aside for advertising or operating expenses and follow it separately. The balance, transaction history, and statement needed to make that easy to understand when they came back.
We launched Pockets on the dashboard and mobile on 8 June, towards the end of my first year at Chowdeck. It brought us back to the question that started this work: what happens after the vendor gets paid?
By then, the money usually already has somewhere to go. The person running the business knows what they need it for. I wanted the wallet to help them carry that intention through, from setting the money aside to understanding how it was spent.