How Much Does a Cash and Voucher Assistance Platform Cost in 2026?

The bands a cash transfer build falls into

These platforms come in three shapes, and the shape follows the number of payment partners and countries rather than the number of households.

• Registration to payment core, $90,000 to $180,000, 14 to 20 weeks. Offline household registration with scoped device data, versioned household composition, an entitlement engine with effective dated formulas, deduplication including a privacy preserving partner matching layer, and payment instruction generation with reconciliation against the operator settlement report.
• Full assistance platform, $250,000 to $600,000, 9 to 15 months. Everything above plus additional payment partners, multi country configuration, vulnerability scoring, electronic voucher redemption at contracted vendors, grievance handling, sanctions screening workflow and donor tranche reporting.
• Electronic voucher redemption, $40,000 to $65,000 inside those bands. Vendor devices, offline redemption, vendor settlement and commodity level restrictions make this closer to a small retail payments system than a feature.

Note what should not be on the list. Biometric identity is not a band, it is a decision that needs a documented risk assessment before anyone estimates it, because it creates a permanent and non revocable identifier held about people who often cannot meaningfully refuse.

What drives a cash transfer build up

• Payment partner count. The dominant driver. Budget $28,000 to $40,000 per additional operator or bank, covering file format, status code mapping, settlement report ingestion, test environment access and the inevitable behaviours the specification does not mention.
• Multi country deployment. The expenditure basket, the accepted identity documents, the regulatory position and the operator landscape all change per country. The first additional country runs $40,000 to $60,000 and the second is cheaper only if the first was built as configuration rather than as a branch.
• Offline capability at real scale. Genuinely more engineering than a connected application, because conflict resolution, scoped caseload distribution, encryption at rest and tested remote revocation are all requirements rather than refinements.
• Consortium deduplication. Not expensive to build once agreed, and expensive in calendar time to agree. The matching layer is engineering. The key set, the governance and the data protection position are negotiations between organisations.
• Biometrics. If a donor requires it, insist on a documented risk assessment and a data minimisation design before a line of code is written, and expect the compliance and testing overhead to exceed the enrolment feature itself.

What keeps the number down

• One country, one programme model, one payment partner in release one. The correct scope for almost every organisation, and it still proves the two things that justify a build.
• Design the partner matching layer in from the start. Retrofitting deduplication is far more expensive than building it, even if you only switch it on for one partner initially.
• Token or card identity instead of biometrics. Solves most of the same operational problem with far less protection risk and far less build.
• Settle the entitlement formula before engineering starts. The schedule risk on these projects is rarely software. It is programme leadership agreeing the formula, the payment partner supplying an integration specification and a test environment, and consortium partners settling the deduplication agreement.
• Manual grievance intake first. A structured case linked to the household record matters more than the channel it arrived through.

A worked example that adds up

A non governmental organisation moving cash to about 50,000 households in one country through a single mobile money operator, working within a consortium of three implementing partners where duplicates are a live disagreement, with enumerators registering offline across districts with no data coverage, an entitlement formula tied to a minimum expenditure basket that has already been revised twice, and a donor that has raised traceability as a concern.

• Offline household registration with caseload scoped to each enumerator, encryption at rest, tested remote revocation and explicit conflict resolution: $41,000
• Versioned household composition and an entitlement engine where formulas carry effective dates and every payment stores the version that produced it: $29,000
• Deduplication within the caseload plus a privacy preserving matching layer exchanging salted hashed identifiers with partners, with a human review queue: $37,000
• Payment instruction generation with deterministic idempotency keys derived from beneficiary, tranche and attempt: $26,000
• Reconciliation against the operator settlement report with an explicit unknown status and an owned unmatched queue: $22,000

First release, $155,000 over about eighteen weeks. Phase two adds a second payment partner in the form of an agent network at $34,000, multi country configuration at $48,000, vulnerability scoring and targeting at $27,000, electronic voucher redemption at contracted vendors at $52,000, grievance and feedback case management linked to the household at $31,000, sanctions screening workflow with reviewer, evidence and documented decision at $29,000, and donor tranche reporting generated from the append only event log at $24,000, another $245,000. Programme total $400,000 across roughly thirteen months.

How the spend phases

About 39 percent lands in the first release, and one sequencing rule overrides everything else. Idempotency has to exist before the first live payment run, not after the first duplicate. It is not a control you add later, because it is derived at the point the instruction is created and a system that checks for existing payments afterwards is relying on someone remembering to filter a resubmission at three in the morning during a partial failure.

Run the deduplication in review mode for one full tranche before it influences any exclusion. Let it produce candidate pairs, have your programme team resolve them, and measure how often the machine was right. A wrongly excluded household is a protection incident rather than a data quality issue, and that distinction has to be built into the workflow rather than left to policy.

Start the payment partner conversation in week one even though the integration ships in week fourteen. Operators control their own test environment access and their own specification release, and that calendar is the most common cause of a missed date on these projects. Ask specifically for the settlement report format at the same time, because reconciliation is the half people forget to request.

Sequence electronic vouchers last. Vendor devices, vendor settlement and offline redemption in a market with intermittent power deserve their own phase and their own field pilot.

The ongoing costs nobody quotes

• Payment partner interface upkeep, $7,000 to $18,000 per partner per year. Operators change formats, status codes and settlement timing, and a drifting interface produces payments you cannot reconcile rather than payments that fail visibly.
• Device fleet, $12,000 to $35,000 a year. Tablets are consumables in field conditions. Replacement, provisioning, encryption key management and revocation testing all recur.
• Hosting, often in region, $10,000 to $30,000 a year. Data residency requirements in several operating contexts push you to specific regions, which is a design constraint with a cost attached.
• Security review and testing, $10,000 to $25,000 a year. A system holding beneficiary data in a displacement setting should be tested by someone other than the people who built it, on a recurring basis.
• Support and enhancement, 15 to 20 percent of build cost annually. On $400,000 that is $60,000 to $80,000. Budget the enhancement half honestly, because entitlement formulas, screening obligations and donor reporting all change within a grant cycle.

Comparing a build against your current renewal

Pull the actual agreement and read what it scales on. Platforms in this sector are commonly priced against beneficiary numbers, programme count or deployment, so the line grows exactly when your caseload grows, which is the moment your budget is already stretched. Model it against your expected caseload three years out rather than today's, and check whether a new country or a new payment partner is inside the fee or beside it.

Then add what the current arrangement costs you in staff time, because that is usually the larger figure. Reconciliation done by exporting operator statements into spreadsheets. Deduplication done in a shared file after enrolment rather than before payment. Donor reports assembled by hand from several systems because no single one holds the chain from selection criteria through registration, verification, entitlement, payment and post distribution monitoring.

The consequential costs are the ones that decide it. A duplicate discovered after payment is money gone and a conversation with a donor. A failed transaction reissued without a reliable idempotency check can become a double payment, and in the cash and voucher work we have delivered, duplicates, unreliable reissue and untraceable reporting are the three recurring failures. The first two cost money directly. The third costs the next grant, which is a larger number than the whole platform.

One honest caution on the comparison. Funding in this sector is annual and teams rotate, so a build has to be affordable in a year where a grant does not renew. If the ongoing figure above cannot be covered from indirect cost recovery on a bad year, buy instead and revisit.

When buying beats building

Buy if you are running a single response with fewer than about 5,000 households, one payment partner, and no cross agency deduplication requirement. RedRose covers registration through payment and has been used at scale. Last Mile Mobile Solutions was built inside a large operational agency and is genuinely designed for field conditions and offline enrolment. Segovia was built around payment orchestration and has real strengths in getting instruction files to operators.

At that size, building your own delays assistance to reach a feature set you do not need, and a slow build in an acute response is a failure whatever the code quality.

Build when two or more of these hold. You operate across multiple partners or a consortium and duplicates are a live disagreement rather than a theoretical one. You run in more than one country with different expenditure baskets and identity regimes. Your payment reconciliation currently happens by exporting operator statements into spreadsheets. Your entitlement formula has been revised more than once and you cannot reproduce which version paid which tranche. Or a donor has already raised a finding on traceability.

Our position has not changed: the two features that justify a build in this sector are idempotent payment handling and cross agency matching. Everything else is configuration. If a demonstration spends forty minutes on dashboards and four on what happens when a batch is resubmitted after a partial failure, you are watching the wrong demonstration and the price on the slide is not the number that matters.

If you would rather scope this before committing budget, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. You keep the specification either way.