When a customer asks for a bank account to complete a large payment privately, protect the relationship before protecting the platform fee. Allow the payment only through a controlled exception that keeps the transaction visible, assigns responsibility and gives both sides a clear reason to return.
At 4:47 on a Friday afternoon, Femi was standing beside a humming generator outside his small office in Yaba when the message arrived. His marketplace had connected a buyer and a supplier, but the payment flow was holding up their order. The buyer wanted a bank account. The supplier was ready to send one.
Femi is an invented composite, but the decision is familiar. If he refused, the two parties could abandon the transaction and possibly the platform. If he shared the supplier’s details, they could complete the payment privately, bypass his thin fee and continue working together without him.
The order was large enough to matter. So was the relationship.
The fee was smaller than the risk around it
Femi’s first instinct was to enforce the product as designed. The platform had made the introduction, organised the order and created the record. The fee paid for that work.
But the customer was not debating the value of the fee. She was trying to complete a purchase before her own deadline. From her side, the platform had become the obstacle at the exact moment it was supposed to help.
That distinction changed the decision.
Blocking the bank transfer might preserve the pricing rule while losing the transaction. Allowing an unrecorded transfer might save today’s order while teaching both parties that the platform could be removed from future ones. Neither outcome was acceptable.
This is where founders sometimes reach for a policy because a policy feels safer than judgment. The product says payments happen here, so payments must happen here. Yet a young platform has limited runway for rigid rules when the underlying workflow still contains gaps.
Femi needed to protect three things in order: the customer’s deadline, the transaction record and the business model.
A controlled exception kept the platform in the room
At 5:06, Femi replied. He would allow the direct transfer, but only under a written exception tied to that order.
The buyer would confirm the amount and payment reference in the platform conversation. The supplier would confirm receipt there. Femi would record that the platform had introduced the parties and supported the order, then speak with both sides after completion about the payment failure.
This did not guarantee the fee. It did something more important at that moment: it prevented the platform from disappearing.
The direct transfer became a visible exception rather than a silent habit. Both parties knew the normal route had failed, and both knew Femi was still responsible for helping the order reach a clear state.
That record mattered. Once payment details start moving through private messages, screenshots and separate systems, a founder can lose the ability to answer basic questions: Who paid? For which order? Who confirmed receipt? Which version of the record should support a dispute? I explored a related risk in What Happens When One Payment Record Multiplies Across Your Systems?.
A controlled exception cannot solve every payment problem. It can buy enough time to learn where the product failed without forcing the customer to carry the cost of that failure.
Friday’s exception became Monday’s product decision
The transfer was confirmed before the evening ended. Femi had not secured the outcome comfortably. Ten minutes earlier, the buyer had been ready to pursue another supplier.
On Monday morning, the useful work began.
Femi did not treat the completed order as proof that direct payments were fine. He treated it as evidence that his payment path had failed under pressure. He reviewed where the buyer stopped, what information she lacked and why a bank transfer felt safer or faster in that moment.
He also asked a harder question: what job did the platform need to keep owning?
If the answer was merely “collect the fee,” customers would route around it whenever collection became inconvenient. If the platform owned the order record, confirmation, support and resolution path, then removing it carried a real cost for both parties.
That is the design test. Your place in the transaction should come from responsibility the customer values, not from hiding contact details and hoping nobody asks.
This resembles the decision behind Fintech Compliance Testing: How Chinedu Built a WhatsApp Off-Ramp He Could Close: when a manual route becomes necessary, define how it starts, what gets recorded and how it closes. An open-ended workaround quietly becomes the product.
The next request needs a rule before it arrives
Femi’s platform now needed a short exception rule his small team could apply without calling him every Friday evening.
The rule had to specify who could approve a direct payment, what evidence stayed in the order record, when the platform fee still applied and what would trigger a product review. It also needed an expiry point. Otherwise, “temporary” would become the preferred payment method.
The deeper choice was no longer fee versus relationship. It was whether to lose control accidentally or preserve control deliberately while the product caught up with the customer’s reality.
By Monday afternoon, Femi had a failed payment path to repair, a completed order in the record and two parties who still knew why the platform was involved. The bank account had solved one urgent transaction. The exception rule would decide whether the next one strengthened the business or quietly removed it.
Comments
No comments yet.