The Maintenance Tax

Engineers have always claimed that building an integration is just the beginning, and that maintaining it is where the real work lives. It's the kind of claim that's easy to nod at and impossible to budget for, because nobody ever quantifies it. We've built and operated 23 stablecoin provider integrations over the past two years, which puts us in a position to quantify it. So we did. We mined our own git history, 647 pull requests across every provider connector in our codebase. 125 of those pull requests built the integrations. The other 522 kept them alive. Eighty percent of the engineering happened after launch.

The question matters more right now than it used to, because of a sentence we hear in almost every planning conversation: adding a provider is trivial now, the AI writes the integration. It usually comes from a CEO who is pushing the whole organization to adopt AI and compress time to market, which is the right instinct. It lands on a CTO whose job is to turn that instinct into a forecast: what does AI actually compress here, by how much, and what should the roadmap assume. The sentence isn't wrong, exactly. We measured how much of it is right on our own codebase, and I'll get there. But first, the number nobody puts in the budget.

When a team scopes a provider integration, they scope the build: read the docs, get sandbox keys, map the quote flow, wire up webhooks, test, ship. Depending on the provider, that's three to eight weeks of real work, and less of it is coding than you'd expect. A meaningful share is communication. This includes waiting on sandbox credentials, chasing compliance questions, getting answers about the API that only the provider's team can give. It's also a fifth of the total investment. The other four fifths arrives after you're live, a little every month, for as long as the integration is carrying your payments.

The other four fifths

Here's what that post-launch stream actually contains, pulled from our own commits:

• A provider adds a required field to their KYB flow without notice, and onboarding starts failing in Argentina.

• A status value gets renamed, and transactions that settled fine start showing as stuck.

• A quote response gets restructured, and amounts parse wrong until the mapping is rewritten.

• Error semantics change, so the same failure starts arriving under a different code and your retry logic handles it incorrectly.

• A compliance requirement appears, with a regulatory deadline attached.

None of these are your bugs, but all of them are your problem, because your customers experience every one of them as your product failing. Each one is also a lesson that only has to be learned once: after the first discovery, the fix exists and the quirk is handled in somebody's codebase forever. Hold onto that property, because much of the economics of this market comes down to who has already done the learning.

What the tax costs

The typical fix is small, a median of 41 changed lines in our history, a targeted patch rather than a rework. The cost is in how often these patches land. A provider carrying real volume needs engineering attention several times a month, and a realistic stack of five providers generates a hundred-plus of these events a year. Do the division and you'll understand why our team stopped thinking of provider maintenance as a project and started treating it as weather.

And the count undersells it, because nearly half of these events arrive within days of the previous one. Provider changes cluster: a migration goes sideways, a fix needs a fix, a new requirement rolls out country by country. This isn't a tidy backlog you can groom on Fridays; it's interrupt work that lands mid-sprint. Earlier this month, one upstream change rippled through five of our integrations in a single week, and I watched a planned sprint quietly lose a third of its capacity to it.

Price it conservatively. Call a blended event half a day to a day and a half of engineering time, covering diagnosis, the patch, sandbox verification, review, and deployment. At 100+ events a year, that works out to roughly a quarter to a full engineer dedicated to this work, at whatever a fully loaded payments engineer costs you, likely $150k to $250k a year across most US and European markets. That's the steady state, and it grows. For example, ours doubled over the past year, because the tax scales with volume. The providers you actually route money through are the ones that change under you, and quiet integrations are quiet precisely because they aren't carrying anything.

If you run the company, the sharper way to think about this cost isn’t the salary line. It’s the work itself. Your integration with any given provider is essentially the same as every other company’s integration with that provider. Every hour your team spends adapting to provider changes is an hour they aren’t spending on the product your customers actually pay for. And unlike a feature, this work only grows as you scale.

The build bill, and the launch date

There’s a hidden line item on the build side too. Your first integrations don’t just cost the weeks it takes to build them. They also force you to build the shared plumbing nobody scopes upfront. This includes normalizing statuses across providers that use different words for the same thing, creating one interface for flows that don’t follow the same shape, and handling retries and reconciliation. Our first two integrations took five and eight weeks each, and we were an infrastructure company staffed to do exactly this.

And the dollars aren’t even the part that stings the most. The build runs largely in series. Every provider has its own sandbox access to wait for, its own KYB process to clear, and its own production validation before you can trust it with real volume. Build and validate five providers one by one, and your launch date can slip by quarters, especially in a market where the corridors you’re targeting get more competitive every month. Most teams that end up on a network aren’t really buying integration code. They’re buying their launch date back.

The changes nobody announces

Provider changes come in two kinds. Announced changes arrive with an email, a changelog entry, sometimes a migration window. They're work, but they're plannable work. Unannounced changes arrive as failed transactions. You find out because money stopped moving and someone has to figure out why.

In our history, roughly one maintenance commit in five is a trivial fix behind an expensive diagnosis. The patch is five lines. The work was discovering that a provider returns rate-limit errors as generic 400s with the real meaning buried in the response body. Or that the account ID you need after a duplicate-account rejection is inside the error payload itself. Or that a retry has to match a misspelled error string, because that's what the API actually sends. None of this appears in anyone's documentation - you learn it from live traffic. And the diagnosis doesn't always end in your own codebase. Some failures are the provider's to fix, and the work becomes chasing them: reporting the issue, waiting while their team investigates, verifying the fix when it lands, all on their clock.

This is where being a network changes the economics, and I’ll be direct that it’s the part we’re structurally better at than anyone integrating alone. Our platform carries transactions from many customers across every provider we support, so when something changes without notice, someone usually runs into it within hours. We diagnose it once, and the fix rolls out across the network. Our largest single fix covered 15 integrations in one pull request.

A company integrating directly discovers the same change on its own timeline, usually because something breaks, and every other company integrating directly has to go through the same process. The industry ends up paying for the same discovery over and over. A network pays for it once and spreads the fix across everyone using it.

Who pays the tuition

It also changes what going live means. A client launching on our network launches on integrations that have already made these discoveries. The misspelled error string is already handled, the duplicate-account quirk already has a code path, and the status that means something different than it says is already mapped correctly. A team going direct starts that learning curve at zero. The tuition gets paid by their customers, in failed first transactions and support tickets, during exactly the window when a new payments product can least afford churn. You don't know what you don't know, and in payments, finding out in production is the expensive way to learn.

"The AI writes the integration"

Now the sentence from the beginning. It earned its plausibility honestly, because the demo is real. Point a coding agent at a provider's API docs and it will scaffold a plausible integration remarkably fast. Concluding from that demo that provider work is now trivial is a reasonable inference. It's also a budgeting error, for reasons the demo never shows you.

Let’s start with what the demo hides. The agent builds against the provider's sandbox, and in this market the sandbox routinely lies. We've seen integrations pass every sandbox test and then fail on real transactions, because the sandbox skipped the compliance gate or simulated the settlement leg instead of exercising it. Some of the connectors we've built never made it past that gap at all. The sandbox worked, the production rail couldn't reliably carry transactions, and the finished integration got shelved without ever going live. We paid for that discovery ourselves, in full, which is exactly the kind of cost a team learns about only after they've committed to the build. Other sandboxes are incomplete enough that there's no way to run automated tests against them at all, which means every future deployment gets verified by hand, forever. And beneath all of that, every rail in every market carries its own unhappy paths. There's the field that's optional everywhere except one country, the bank holiday calendar that shifts settlement timing, and the error that means retry on one provider but stop immediately on another. An agent can't one-shot a process when the pieces it needs to verify its own work don't exist, and no amount of model intelligence conjures a production-faithful sandbox into being.

We measured this instead of guessing. We went through 37 of our own maintenance diffs one by one and classified them. About a third were mechanical changes an agent could handle on its own. The biggest group was changes an agent could draft but a human still needed to verify, because “looks right” isn’t enough when the code prices and moves money. Another 20% to 30% still required a human from start to finish. Overall, agents cut the cost of writing integration code by roughly half, for us and for you.

Here’s what they don’t cut. An agent can’t know that a provider changed its webhook behavior yesterday. You only find that out from production traffic. Diagnosing the issue means looking at production logs and recognizing the failure pattern. In our audit, the most expensive fixes were exactly the ones an agent could never have started. The code itself was easy. Knowing what was wrong was the hard part.

And one more honest caveat about that halving. Agents get better the more context they have. The performance I just described is what they achieve inside an organization with dozens of provider integrations in the repo to pattern from, riding shotgun with engineers who each have dozens of reps working with these providers. That context layer took us two years to accumulate. An agent starting from a provider's docs alone starts without it, and so does the team running it.

The forecast for the roadmap

So here’s what the data suggests for that planning conversation. The CEO is right to adopt the agents and hand them the mechanical parts of the work right away. The gains are real. The CTO is right too, but the halving applies to the code, and the code was never what held up the launch. The real bottlenecks are sandbox access, KYB with each provider, production validation, and the issues that only show up once you have live traffic. Those things run on the providers’ timelines, not the model’s. AI can make the coding part much faster, but that was never the expensive part of the timeline. The calendar the roadmap cares about barely moves.

Coding agents halve the cost of writing integration code. They don't touch the cost of knowing what to write. The expensive half of the maintenance tax was never the code.

Budget honestly

So budget honestly, in both currencies. In dollars, if you're integrating providers directly, that means a standing fraction of an engineer per handful of providers, growing with your volume, plus an on-call answer for the changes that announce themselves as failures. In time, it means a launch date that moves with every provider you add in series, and a learning curve whose tuition gets paid in production. Ask each provider how they communicate changes before you sign. If they can't answer, you just learned how they communicate changes.

If you're evaluating a platform instead, ask one question: how many provider-driven changes did you ship last quarter? We know our number because we went and counted. Anyone doing this work for real will have one too.