How Much Does Deposit Return Scheme Software Cost in 2026?
Deposit return scheme software runs $90,000 to $600,000, and the decision that moves the number most is how many reverse vending hardware vendors you have to read session level events from. One vendor across your estate keeps you in the lower band.
On this page
Deposit return scheme software runs $90,000 to $600,000, and the decision that moves the number most is how many reverse vending hardware vendors you have to read session level events from. One vendor across your estate keeps you in the lower band. A mixed fleet of TOMRA and Envipco machines inherited through acquisition means a separate adapter per vendor, each normalising a different event model into yours, and in our delivery experience that is real engineering rather than a configuration screen. Every additional hardware vendor also multiplies the reconciliation testing, because a session has to mean the same thing regardless of which machine produced it.
The bands a deposit return build falls into
Two bands cover the work, and the split is not site count. It is whether you are building a reconciliation layer or a full deposit operations platform.
- $90,000 to $190,000, fourteen to twenty weeks. A focused first release: machine event ingestion for one hardware vendor at session level, point of sale (POS) voucher issue and redemption capture, three way reconciliation between what the machine accepted, what the store refunded and what the scheme pays back, an exception queue with named break reasons, and claim file generation for one scheme. This is the release that turns an unexplained monthly variance into a short list somebody can actually work.
- $220,000 to $600,000, eight to fourteen months. The full platform: a second or third hardware vendor, manual over the counter takeback capture, fraud pattern detection with an investigation queue, handling fee modelling and forecasting, collection and logistics tracking, and multi scheme settlement where you operate across a border.
There is a gap between the bands rather than a smooth curve, and that is deliberate. The first release is a self contained piece of work with a defined output. Everything after it is a programme, and pricing it as a slightly larger version of phase one is how these projects overrun.
What drives a deposit return build up
Hardware vendor count is the first driver. Each adapter has to consume session level events with container detail rather than a daily summary export, handle machines that were offline for hours and then upload their backlog, and do it idempotently so a replayed batch does not double count. What a vendor will expose to a customer varies, and finding that out is discovery work rather than a line item you can price blind.
Point of sale integration is the second, and it is almost entirely a function of how old your till estate is. On a modern cloud point of sale, voucher issue and redemption arrive as structured events and the work is modest. On an older estate where a voucher redemption is a barcode scan against a generic tender type with no structured record, you are extracting the data from journals or working with your till supplier to expose it, and that conversation sets your timeline more than the engineering does.
Site count drives cost mainly through connectivity rather than volume. Stores lose network. The system has to tolerate late arriving events, out of order events and repeated events without corrupting a claim period that has already been reported. Designing for that from the start is cheap. Discovering it in month four is not.
Fraud detection depth is the third real driver. A single duplicate identifier check is small. Pattern detection across sessions, sites and shifts, producing a ranked investigation queue rather than an alert wall, is a proper piece of analytical work with a feedback loop from the loss prevention team who use it.
Counting centre integration is the driver most often missed at quote stage. Weight and count data coming off industrial equipment is not an API in the sense a web developer means it, and if your claim depends on reconciling against a counting centre figure, budget for it explicitly.
What keeps the number down
Start with your highest volume thirty or forty sites and one machine vendor. Those sites carry most of the cash and most of the variance, and proving the reconciliation there costs a fraction of proving it everywhere. Rolling the rest out afterwards is deployment work, not development work.
Run the reconciliation in observation mode for a full claim period before it drives anything. This sounds like it adds time, and it does add calendar, but it removes the most expensive category of change: the rule that was written from how finance described the process rather than from how the process actually behaves. Every operator we have worked with found at least one such rule during observation.
Leave manual takeback capture, fraud detection and handling fee forecasting to phase two. None of them is useful until the core three way match is trusted, because every one of them reads from it.
And keep your claim file generation to one scheme in the first release even if you operate across two. The second scheme is an output format and a rule set layered on the same internal model, which is a much smaller piece of work once the model exists and a much larger one if you try to design for both at once.
A worked example that adds up
A grocery chain running reverse vending across 180 stores, two machine vendors from an acquisition, a mixed till estate, and one scheme. They want the full platform because handling fee income is a line their finance director watches and a claim was adjusted last year without explanation.
- Discovery, event and reconciliation model agreed with finance and operations: $14,000
- First hardware vendor adapter, session level events with idempotent replay handling: $26,000
- Second hardware vendor adapter normalised into the same internal model: $22,000
- Point of sale voucher issue and redemption ingestion across an older till estate: $34,000
- Three way reconciliation engine with exception queue and named break reasons: $38,000
- Claim period object with audit trail down to individual session, plus scheme file generation: $24,000
- Claim status tracking from submission through acceptance, adjustment and payment: $12,000
- Manual over the counter takeback capture on handhelds: $16,000
- Fraud pattern detection with a ranked investigation queue: $30,000
- Handling fee modelling and finance reporting: $18,000
- Rollout across 180 sites, observation period and training: $20,000
That totals $254,000 across eleven months, which sits in the lower half of the full platform band. Drop the second vendor adapter and everything below claim generation, leaving discovery, one adapter, point of sale, reconciliation and claim file generation, and you have $136,000 shipping in around eighteen weeks. That subset is the whole first band, and it is where most of the recoverable money actually is.
How the spend phases
Pay for discovery separately and first. In this category discovery has a concrete deliverable: a written answer to what your machine vendor will actually expose, what your point of sale can actually produce, and what the scheme's file format and evidence requirements currently are. If any of those three answers is worse than assumed, you want to know before committing the rest.
Then phase against the reconciliation, not against features. Ingestion first, because nothing else can be tested without real events flowing. Reconciliation second, running in observation mode against a live claim period. Claim generation third, run in parallel with your existing spreadsheet process for one full period before you switch. Only after a period has been claimed successfully from the new system should fraud detection and handling fee modelling start, because both depend on the reconciled data being trustworthy.
Hold ten to fifteen percent back for the period after the first live claim. There will be adjustments, and you want budget attached to the team that understands why.
The ongoing costs nobody quotes
Event storage is the cost specific to this category. You are keeping session level events with container detail, append only, for as long as your scheme's evidence requirements demand, and that is a larger volume than most retail systems generate. It is not expensive per unit but it is not free and it grows every month, so model it over five years rather than one.
Beyond that, budget a maintenance retainer at fifteen to twenty percent of build cost per year. In deposit return this retainer earns its keep more than in most categories, because two things change on somebody else's timetable. Scheme rules move, including file formats, handling fee schedules and evidence requirements, and when a regulator revises them you do not get to choose when. Machine vendor interfaces also change with firmware releases, and an adapter that stops receiving a field is a silent failure unless somebody is watching for it.
Add monitoring and alerting as a deliberate line rather than an afterthought. The failure mode here is not a system that goes down. It is a machine that stops reporting while everything else keeps running, which is why feed liveness checks matter more than uptime dashboards.
Comparing a build against your current renewal
Most retailers have no licence line to compare against, which makes this comparison harder rather than easier. What you are actually comparing is the build against the cost of the current situation, and that cost is real but scattered.
Add up four things. The finance and operations hours spent each claim period reconciling machine reports, till data and the scheme statement, priced at loaded salary. The value of claim adjustments you accepted in the last two years because you could not defend the count. Your best estimate of handling fee income lost to sessions that never made it into a claim because a machine was offline and nobody chased it. And any fees you pay for machine vendor fleet portals beyond the hardware service agreement.
Then be honest about the fourth number, which most operators cannot produce at all. If you cannot say how many machine hours were offline and unaccounted for last quarter, that is not evidence the number is small. In the deposit projects we have delivered, the first report showing offline and unreconciled machine hours has consistently come in higher than the operations team expected, and that report is available from the first release.
When buying beats building
If you run a small number of stores with a single machine vendor under one straightforward scheme, do not build. The vendor fleet software from TOMRA or Envipco plus a monthly export genuinely covers you, and the reconciliation risk at that volume is small enough to absorb without software. Their portals are good at machine health, uptime, bin levels and service dispatch, which is what matters most when your estate is small and homogeneous.
Do not build if you are preparing for a scheme that has not launched yet. Specifications and dates in this sector have moved more than once, and building against a draft means paying for the same work twice. Confirm the current position with your scheme administrator before designing any validation logic against it.
Build when the small numbers become large through volume. That means a mixed hardware estate across enough sites that no single portal shows your position, handling fee income that your finance team treats as a line rather than a rounding error, a claim you have already been challenged on and could not defend, or a scheme operator role where your credibility with member retailers rests entirely on settlement accuracy. Scheme operators almost always end up building, because no packaged product implements another jurisdiction's rules and there is no market of competing products for a scheme document that applies to one country.
If you would rather scope this before committing budget, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. You keep the specification either way.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Only about 30% of digital transformations succeed at meeting their objectives, but getting six critical success factors in place (leadership commitment, talent, agile culture, progress monitoring, clear strategy, and a modernized platform) raises the odds of success from 30% to 80%. Source: Boston Consulting Group (BCG) (2020) →
- The median annual wage for U.S. software developers was $133,080 in May 2024, and employment is projected to grow 15% from 2024 to 2034 - a core input to any in-house build-vs-buy TCO model. Source: U.S. Bureau of Labor Statistics (2024) →
- WordPress powers 41.5% of all websites and holds 59.2% of the market among sites running a known content management system, making it by far the most-used CMS on the web. Source: W3Techs (2026) →
- Qualtrics research (Q3 2023 survey of ~28,400 consumers across 26 countries) estimated bad customer experiences put roughly $3.7 trillion in global revenue at risk annually, a 19% jump from the prior year's $3.1 trillion; 64% of customers say they will switch companies over poor service regardless of how much they like the product. Source: Qualtrics XM Institute (via Forbes) (2024) →
Frequently asked questions
What is the total cost of custom deposit return scheme software?
A focused first release covering machine event ingestion for one hardware vendor, point of sale voucher matching, three way reconciliation with an exception queue and claim file generation for one scheme runs $90,000 to $190,000 and ships in fourteen to twenty weeks in our delivery experience. A full platform adding a second hardware vendor, manual takeback capture, fraud detection, handling fee modelling and multi scheme settlement runs $220,000 to $600,000 across eight to fourteen months. Hardware vendor count and till estate age drive the number far more than store count does.
What does it cost to run each year once live?
Budget a maintenance retainer of fifteen to twenty percent of build cost per year, plus cloud hosting with an event storage line that grows every month because you are keeping session level events append only for as long as scheme evidence rules require. Model that storage across five years, not one. The retainer earns its keep here specifically because scheme file formats, handling fee schedules and evidence requirements change on a regulator's timetable, and machine vendor interfaces change with firmware releases.
How long does a first release take?
Fourteen to twenty weeks. The pacing item is almost never the engineering. Getting session level data with container detail out of your machine vendor, and getting structured voucher redemption out of an older point of sale estate, both take longer than writing the code that consumes them. Add a full claim period of running the reconciliation in observation mode before it drives any decision, which is calendar time worth spending because it is where the rules get corrected.
Why does a second machine vendor add so much?
Because a session has to mean the same thing whether the machine is a TOMRA or an Envipco, and the two do not describe one. Each adapter consumes a different event model, handles offline backlog upload differently, and exposes different container detail, so the second adapter benefits only modestly from the first. In the worked example above the two adapters were $26,000 and $22,000 against a $254,000 total. The reconciliation and fraud logic above them is written once, which is the whole point of normalising.
Is TOMRA or Envipco fleet software enough on its own?
For a small single vendor estate, yes, and building would be wasted money. Their portals are genuinely strong on machine health, uptime, bin levels and service dispatch. What they cannot cover is your point of sale, so voucher redemption is invisible to them by construction, and each manages its own fleet rather than a mixed estate. Once you run two vendors across many sites and handling fee income matters to finance, you need a layer above both rather than a better portal.
What is the cheapest useful thing to build first?
One hardware vendor, your highest volume thirty or forty stores, point of sale voucher matching, the three way reconciliation and claim file generation for a single scheme. That is roughly $136,000 in the worked example above and ships in about eighteen weeks. Those sites carry most of the cash and most of the variance, so the reconciliation proves itself where it matters, and rolling the remaining sites out afterwards is deployment rather than development.
How much does fraud detection add to the budget?
Around $30,000 in the 180 store example, and it belongs in phase two rather than phase one. It is worth that only once the underlying reconciliation is trusted, because pattern detection reads from reconciled sessions. What you are paying for is repeated identifier detection, session volume outliers by site, acceptance rate shifts by shift, redemption clustering by till and out of jurisdiction barcode ranges, combined into a ranked investigation queue rather than an alert wall that loss prevention will learn to ignore.
Do we need a separate build for each scheme we operate in?
No, and doing so is the expensive mistake. Keep one internal container and session model, then layer scheme specific rules and output formats on top, so a second jurisdiction is a configuration and adapter exercise rather than a second system. Build the first release against one scheme even if you operate in two, because designing for both simultaneously costs more than adding the second once the model exists and has survived a live claim period.
How do we justify the spend to a finance director?
With four numbers rather than a feature list. The finance and operations hours spent each claim period reconciling machine reports, till data and the scheme statement at loaded salary. The value of claim adjustments accepted in the last two years that you could not defend. Handling fee income lost to sessions that never entered a claim because a machine was offline. And any fleet portal fees beyond your hardware service agreement. If you cannot produce the third figure at all, that is the argument rather than a reason to skip it.
If an agency builds my software, who actually owns the code?
You should own everything, assigned in writing: the contract transfers full IP to you on final payment, the code lives in your GitHub organization, and hosting runs in cloud accounts you control. The red flag is a proposal that mentions the agency's proprietary platform or framework, which usually means you are renting, not buying. Digital Heroes structures every build this way precisely so a client can fire us and lose nothing but the relationship.
Is it cheaper to customize Salesforce than to build a custom CRM from scratch?
If you use less than a third of what Salesforce does, a custom CRM is often cheaper by year three. Salesforce Enterprise lists at $165 per user per month, so 25 seats cost about $49,500 a year before admin and consultant fees, while a focused custom CRM runs $60,000 to $100,000 once plus 15 to 20% a year in maintenance. If you genuinely need Salesforce's ecosystem, reporting, and app marketplace, customizing it beats rebuilding it; the mistake is paying enterprise prices to use it as a glorified contact list.
How many people should be working on my software project?
Three to five for a typical focused build: a project lead, one or two engineers, a designer, and part-time QA, which is the standard shape across 2,000+ Digital Heroes projects. Larger platforms justify 6 to 10, but a ten-person team on a small first version usually signals bill padding rather than horsepower. What predicts success is whether a senior engineer is writing your code daily, not the headcount on the proposal.
Couldn't I just build my app in Bubble or another no-code tool instead of hiring an agency?
For validating an idea with real users, yes, and we tell clients that honestly. The walls come later: Bubble apps cannot be exported as code to run anywhere else, performance drops on complex data operations, and usage-based pricing climbs as you grow. A meaningful share of Digital Heroes custom builds are rebuilds of no-code MVPs that proved the business worked, which is the system operating as intended: validate cheap, then build the version that scales.
Should we build an MVP first or go straight to the full system?
MVP first, for almost everyone: ship the single workflow that carries the business value in 10 to 16 weeks, learn from real users, then fund phase two from evidence instead of guesses. The caveat is that an MVP is a small version of a well-built system, not a badly built version of a big one; the data model must already support what comes next. An agency that cannot tell you what they deliberately left out of your MVP has not designed one.
How do I make sure custom software is secure and compliant with rules like HIPAA?
Start with the baseline every business system should have: encryption in transit and at rest, role-based access control, and audit logs. If HIPAA applies, the hosting provider must sign a Business Associate Agreement, which AWS, Azure, and Google Cloud all offer, and access controls have to be designed in from day one, not bolted on. SOC 2 certifies a company's operating practices, not a codebase, so ask vendors what they have shipped in your regulated domain rather than which logos are on their website.
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
More from Harper.
Senior Account Director · APAC · Sydney · 2 posts on the site
Published · Last updated .
