Who owns your payment system? If you had to think, that’s the problem.

In almost every organisation I’ve worked with, the same conversation happens around payment systems. I suspect you’ve had a version of it.

Ask yourself: who owns your payment solution? Do you have an answer without thinking about it? And, perhaps more importantly, would the person you’re thinking of agree that it’s them? Most organisations have a reasonable understanding of who the main users of a system are — though not always, and we’ll come back to service catalogues another time — but ownership is a different question entirely.

What follows isn’t a story about bad practice or negligent teams. The people I’ve worked with — in charities, in growing businesses, in membership organisations — are dedicated, capable, and stretched. What I’ve found, across organisations of different sizes, different sectors, different levels of digital maturity, is a structural gap that almost nobody has designed their way out of. Income teams and technical teams have divided responsibility for the tools that process payments, and in that division, genuine ownership has often disappeared entirely.

The income or sales team relies heavily on the payment platform. They live and die by the numbers it produces. But they handed the technical implementation to someone else — and understandably so, because configuring payment integrations isn’t their job. The technical team, meanwhile, knows how the tool works. But they may not fully understand the customer journey it supports, the data it needs to produce for reporting, or what a silent failure looks like to a sales manager or fundraiser checking a dashboard on a Monday morning.

So nobody owns it. Not really. And that arrangement holds up fine — until it doesn’t.

In my experience, the moment it stops holding up is almost always a crisis. Not a flag raised by an audit, not a supplier getting in touch, not a new joiner asking the right questions. A crisis. By the time it surfaces, income has already been affected, customers or donors have already lapsed, and the gap between what the platform was supposed to do and what it has actually been doing has quietly widened over months.

This piece is a diagnostic. It won’t fix the problem — but it will help you see it. And in most of the organisations I’ve worked with, that visibility is what was missing.

 

Why this is harder to spot than it should be

Most leaders think about income resilience in terms of sources. They ask: are we too dependent on one income stream? Are we building our customer or supporter base? Do we have enough recurring, predictable revenue?

These are the right questions. But they’re only half the picture.

An organisation can have four income streams and a single point of failure. That failure isn’t losing a single customer or funder — it’s a payment integration running unattended, a data connection nobody has checked, an automated process with no named owner. It’s infrastructure, not income. And it rarely appears on a risk register until it has already caused a problem.

What follows is a set of five questions — one for each dimension of digital income dependency. They are designed to be worked through as a leadership team, not answered alone at a desk. The places where you can’t give a confident answer are the diagnostic. That’s where the work is.

The five dimensions

1. Payment infrastructure — who actually owns this?

Your income flows through technology. Payment pages, direct debit processors, CRM integrations, payment gateways — there may be more of these in your organisation than anyone has ever listed in one place.

The question isn’t whether these tools work. It’s who owns them in the full sense: who understands what they do, who monitors them, who would know if something changed or failed, and who has the access and authority to fix it.

In practice, I’ve found that ownership of payment infrastructure tends to fall into a gap between teams. The income or sales team depends on the tool but has handed responsibility for it to technical colleagues. The technical team can maintain the tool but may not understand the customer journey it supports or the reporting data it needs to produce. When something goes wrong, both teams look to the other.

The red flag: You can name the tools your income runs through, but you cannot name a single person who is accountable for each one end to end — from the customer’s experience at the point of payment, to the data that appears in your finance reports.

The question to ask in the room: For each payment tool your organisation uses — who is accountable for it working correctly, from the customer’s perspective to the finance team’s? Not responsible for a part of it. Accountable for the whole thing.

2. Platform dependency — how much of your customer base do you actually own?

Platforms you don’t control — marketplaces, aggregators, social media channels, email deliverability services, search rankings — are often a significant source of customer acquisition. That’s not inherently a problem. The problem is when those platforms become load-bearing parts of your income model without anyone making a deliberate decision about the risk that entails.

If a key platform changes its fee structure, its ranking algorithm, or its terms of service, how exposed are you? If your primary acquisition channel shifts — as social media reach has done repeatedly over the last decade — how much of your existing customer or supporter base can you still reach directly?

The measure of platform dependency isn’t how much income comes through a given channel. It’s whether you have a direct, owned relationship — an email address, a standing order, a phone number — with enough of your customers that a platform disappearing tomorrow wouldn’t take them with it.

The red flag: A meaningful proportion of your customers or donors came to you through a platform you don’t own, and you have no direct contact with them outside of that platform.

The question to ask in the room: If every third-party platform your organisation uses was unavailable tomorrow, what percentage of your customer or supporter base could you still contact directly — and what would that mean for your income?

3. Data connectivity — can you see income risk before it becomes an income problem?

Lapsing customers leave signals before they leave. A missed direct debit, a decline in email engagement, a key relationship that’s gone quiet — these things appear in your data before they appear in your accounts. The question is whether your infrastructure connects that data clearly enough for anyone to act on it in time.

In many of the organisations I’ve worked with, customer data lives in one system, finance data in another, and communications in a third. Nobody has joined them together. The result is that early warning signals — the kind that would allow an account call or a re-engagement campaign before someone cancels — only become visible after the income has already gone.

This isn’t a technology problem, fundamentally. It’s a design problem. The systems exist; they just haven’t been connected in a way that serves the team’s decision-making.

The red flag: Your team finds out a customer has lapsed, or a key relationship has cooled, significantly after the point at which intervention would have been possible.

The question to ask in the room: What would you need to see, and how quickly, to catch an income problem three months before it became a crisis — and does your current infrastructure show you that?

4. Automation fragility — is anyone checking the things that run themselves?

Automated income processes are easy to set up and easy to forget. Welcome emails, payment retry sequences, subscription renewal reminders, lapsed customer reactivation flows — when they work, they’re invisible. Which is precisely why they’re vulnerable.

The risk isn’t that these processes were set up incorrectly. It’s that they were set up correctly at a point in time, and nobody has systematically checked whether they’re still running correctly as systems have changed, staff have moved on, and integrations have quietly drifted.

For charities, Gift Aid is a telling example. It’s worth significant income to most organisations that can claim it — and yet the reclaim process is often automated and rarely audited. A submission that stopped working six months ago won’t announce itself. It will just stop producing income, and that gap will only become visible when someone thinks to look. The same pattern appears in subscription businesses with failed payment retry logic, or in membership organisations whose renewal sequences silently stopped firing after a platform migration.

The red flag: You have automated processes touching your income that were configured by someone who no longer works at the organisation, and nobody has formally verified them since.

The question to ask in the room: List every automated process that touches your income. When did you last confirm that each one is running correctly — not assumed, but actually verified?

5. Human single points of failure — what lives in one person’s inbox?

Some of your most valuable income relationships exist primarily in the memory and contact book of one person. A major donor who gives because of a relationship with your CEO. A long-standing client whose account is held by one relationship manager. A key partner whose entire history lives in a single person’s email.

These relationships are real and they have genuine value. The question is whether they are documented, known to more than one person, and managed through systems that would survive a staff departure or an extended absence.

This is not about replacing the human relationship — it’s about ensuring that when the person who holds it leaves, the organisation doesn’t lose the relationship too. The contact history, the preferences, the context that makes a renewal conversation possible — if those things live in a personal email account rather than a shared CRM, they are one resignation away from disappearing.

The red flag: You can identify relationships where, if a specific person left tomorrow, the organisation would have no documented basis for continuing them.

The question to ask in the room: Which of your income relationships are most dependent on a single individual — and what exists in your systems to protect them if that person leaves?

How to use this

This works best as a leadership team conversation, not a solo exercise. Set aside sixty to ninety minutes. Work through each dimension together. The goal is not to score yourselves or produce a report — it’s to identify where you can answer confidently and where you pause.

The pauses are the diagnostic. They tell you where the risk actually lives.

Most organisations will find two or three dimensions where the answer is genuinely unclear. That’s not failure — that’s the honest starting point. The value of this exercise is visibility. Once you can see where your income infrastructure is fragile, you can make deliberate decisions about what to address and in what order.

You don’t need to fix everything at once. You need to know what you’re carrying.

The organisations I’ve worked with that have come through income pressure in better shape than their peers weren’t always the ones with the most diversified income on paper. Some of them had fewer streams. What they had was a clearer view of their own infrastructure — they knew where they were dependent, they’d made conscious decisions about those dependencies, and they had people who could act quickly when something changed.

That clarity doesn’t come from technology. It comes from having the conversation. This is a reasonable place to start.

 

To explore how Cawood approaches digital income infrastructure as part of a wider digital maturity assessment, visit cawood.io