Writing

A Farmer Has Been Paid Only When the Money Reaches the Right Account

The Korosho programme brings an everyday question into focus: what happens between preparing a payment and the farmer receiving it?

Garang Mayom Malek · Published 24 September 2026 · Updated 24 September 2026 · 2 minute read

Soma kwa Kiswahili ↗

Preparing a payment file is an internal milestone. The farmer’s milestone is receiving the money. Keeping those two moments distinct is a useful starting point for designing agricultural payments.

CapitalPay describes a programme with Korosho Cooperative Joint Enterprise Ltd to check farmer bank-account details before disbursement. Its public description places the work at pilot-preparation stage. That creates an opportunity to test the whole experience, including the cases where details need correcting.

A check should lead to an answer

Imagine a payment that cannot proceed because the account details need attention. The useful outcome of a check is an answer the farmer and cooperative can act on. Which detail needs correction? Who can submit it? How will they know it has been accepted?

A system should make the route through those questions short and understandable. Sending the same unresolved record back through a payment process adds work without explaining the cause. A clear exception queue gives staff somewhere to begin.

Correction also needs care. Changing where a payment will be sent is consequential. The people handling it should have a defined role, an appropriate confirmation process and a record of the change. The farmer should receive an understandable explanation through an agreed contact method.

Follow the payment beyond submission

A useful status sequence distinguishes details awaiting correction, a payment prepared for submission and confirmation of the outcome. The exact steps depend on the banking arrangements. The user-facing language should match what the system can actually establish.

If an attempted payment is returned, the record should retain that history and the resolution. A later success should make it possible to trace what changed. That helps staff answer the person waiting for payment and reconcile the cooperative’s records.

These are proposed design standards for a payment journey. Their value can be tested by asking users to complete real tasks and explain what they understand from the status they see.

What a pilot should report

I would want a pilot report to identify the period covered, how many payment attempts were included and how many reached each outcome. It should explain the common reasons for correction and how long those cases took to resolve.

It should also capture whether farmers could access help. A technically successful process can still be difficult to use if instructions are unclear or support is hard to reach. Brief, consented feedback can reveal problems a transaction count misses.

The Korosho project page records the published stage and the next progress information to look for. The test of the work will be the experience of receiving payment and resolving the exceptions that stand in its way.

Filed under Tanzania.