“We’ll Just Build It Ourselves”

Every few weeks a team tells us some version of the same thing: “We looked at your product. We’ll point Claude at the payment providers’ docs and integrate on our own. Why should we pay you?”

Fair question. We build cross-border stablecoin payment infrastructure for a living, so of course we think it’s harder than it looks.

The short version of our answer fits in one scene. Some Friday evening, a large transfer will leave one bank and never arrive at the other. The dashboard will say “processing”, support will promise a reply within two business days, and your client will be calling every hour. Someone will have to pick up the phone and go find that money. The whole build-or-buy question comes down to who that someone is.

This is not an article about AI being overrated

We won’t answer the question with “AI can’t do it”. We write our own code with Claude every day, and it’s wonderful. And yes, Claude will write your integration. It's just that writing the integration was never the expensive part.

So this article is not about whether Claude can write the integration. It can. The rest of this article is about everything the integration is not: what week one actually looks like, the jobs that never end once you're live, and who you're really depending on when a provider has a bad Friday.

AI didn't make the work smaller. It made it look smaller. Smart teams now walk into cross-border payments certain about things they haven't run in production yet. We recognize that confidence, because it used to be ours. What follows are the scars it cost us.

Week one is not what you think

Here’s the plan: Claude reads the docs, writes the client, two weeks later you’re live. The plan feels solid, because so far everything you know about the provider came from their docs and their sales team. The docs are unverified. The sales team is paid to sign you.

Here’s how week one actually goes. The sandbox returns errors that appear nowhere in the docs. You ask in the shared Slack channel with the provider. The answer comes the next day: “we’re checking with the team”. The person in that channel is support, not engineering, and the engineers are two hops away. On day three someone asks you to resend the request ID. Maybe they know where the bug is. Maybe they’re discovering it together with you, and “we’re checking” is how they buy time. Meanwhile one payment method turns out to need a field the docs never mention, which you find out by being rejected. On Thursday the test environment quietly goes down, unannounced, so you spend a day debugging your own code. It was fine all along.

None of this is Claude’s fault. Claude did its part in an hour. But you’re no longer integrating with documentation. You’re integrating with a company. And the timeline you showed your CEO is already wrong.

There's research on why the timeline felt right anyway: in METR's randomized trial, experienced developers using AI tools guessed they were 20% faster. The stopwatch showed them slower. METR's 2026 update says the tools have improved since, but the gap between feeling and measurement stayed. Feeling fast and being done are two different things.

We know, because we’ve done this dozens of times. Documentation is a theoretical. Production is reality.

The stories the docs will never tell you

Something worth understanding about the providers who actually move money in and out of local banking systems: they are young companies. Most are somewhere around a Series A. Some started as trading desks and grew an API later, which means the API might be the third priority in building, after the license and the banking relationships. They’re good companies doing a genuinely hard job. But their APIs reflect that priority list. A few true stories from our own history, names removed:

• Some rails can’t be tested at all. One provider offers part of its network only in production. There is no sandbox for it. The first test is the real thing.

• Breaking changes arrive without warning. New required fields have appeared in a provider’s onboarding flow overnight. Webhooks have changed shape with no version bump and no email; we found out when production started rejecting them in the middle of the night. Since then, every parser we own is tolerant by design.

• Most providers are built to pass functional tests, not to survive load. Everything works at a hundred transfers a day. At a thousand, timeouts and rate limits appear, and the real limits are rarely in the docs. We learned one provider’s actual numbers by hitting them and once shipped two hotfixes in a single week just tuning our retries around their throttling.

• Error messages often explain nothing. For one provider we ended up building a full reverse-map of their bank-field errors, a translation table from what they say to what a human can actually fix.

• And the small betrayals: amounts that turn out to be in cents when you expected whole units, idempotency keys that don’t quite guarantee idempotency, minimum amounts you discover by rejection, compliance requirements that change after you’re live. Retroactively.

Every one of these cost us a hotfix, and some cost us an incident. That was the tuition. It’s paid now, and it doesn’t transfer by reading about it.

The happy path is a demo

The flow Claude builds you is beautiful: request a quote, create a transfer, wait until it settles. That’s the demo, and maybe 20% of the work.

The other 80% is what money does when it doesn’t settle. A local bank rejects a payout after the stablecoin side has already settled. Where does the money sit now, and in whose ledger? A refund starts, and every provider does refunds differently: different statuses, different triggers, different timelines, barely documented. A transfer freezes as neither failed nor completed and stays that way for days. A webhook arrives twice. Or out of order. Or before the status it announces.

We keep an internal refund playbook for every provider we work with, because none of that knowledge exists in anyone’s docs. It was earned incident by incident. A quick test for your own plan: count the states in your transfer state machine. Fewer than fifteen means you haven’t met the others yet.

This is also where AI-written code gets dangerous. The problem is not quality, it's the failure mode. Claude handles every case you thought to describe, and the cases above are exactly the ones nobody thinks to describe. Async is the worst of it: in our own daily work, queues, retries and out-of-order events are where we watch Claude struggle hardest, because correctness stops living in one file and starts living in time. So the code works in the demo, passes the tests, and breaks three months later on the retry nobody simulated. In a normal product that's a bug ticket. In payments it's someone else's money stuck in an unknown state.

The two-week estimate is starting to stretch.

The jobs that never end

Even when nothing is broken, three quiet jobs run underneath payment infrastructure, forever. Nobody plans for them, because nobody knows they exist until the first incident.

Reconciliation. Your ledger says one thing, the provider says another, the blockchain says a third. Differences between them are not an “if”. They are a “when”. And reconciliation is not a script. It’s a designed process, with owners and escalation paths, and it has to exist before the first discrepancy, because designing it during one means designing it while money is missing.

Rate watching. The provider who won your price comparison will not be the cheapest in six months. Corridors reprice. Spreads drift. Nobody sends you an email about it. We run continuous price benchmarks across providers, because a rate that’s competitive today goes quietly uncompetitive tomorrow. That’s a system someone must build, and a job someone must own. And there's a harder question underneath: benchmarked against what? Providers' public websites show retail rates that have little in common with contracted ones. The only honest data set is live quotes pulled from many providers at once, and you only have that if you're integrated with all of them. With one integration you don't just risk a bad rate. You lose the ability to know it's bad.

Provider health. Settlement times degrade quietly. There is no status page for “slower than usual”. You find out from your users, in support tickets, days later. Unless something is watching.

Each of these is backlog you didn’t plan. It won’t wait its turn politely. It will eat your product roadmap, feature by feature.

The two-week estimate now looks more like a quarter.

“But aren’t you a single point of failure too?”

Young infrastructure companies lose banking partners, leave markets, get acquired, and sometimes die. That’s not pessimism, that’s the recent public record. In 2023, crypto’s two main dollar rails disappeared over a single weekend when Silvergate and Signature banks went down. In 2024, Synapse, the layer many US fintechs were built on, collapsed and froze roughly $100M of end-customer money for months. Stripe bought Bridge for over a billion dollars, so the provider you integrate today can wake up tomorrow as someone else’s subsidiary, with someone else’s pricing. And in Europe, MiCA pushed the world’s most traded stablecoin off regulated exchanges, a whole region where one asset quietly became unusable.

An integration is a photograph of the market on the day you wrote it. The market is a video.

That’s the case against building on a single provider. And right here comes the sharpest objection we hear, sometimes to our face: “You’re one integration too. If your network goes down, all our payments go down. At least building direct, we control our own destiny.”

Let’s take that seriously, because it’s the best argument in the room. Start with what “down” actually means. When a software layer has a bad day, transfers are delayed. Payments in flight are durable, they resume from where they stopped, and the incident is measured in minutes. When a provider dies, money is frozen, and that’s measured in weeks or months. Ask anyone who was built on Synapse. Nobody can promise you zero failures. What a network does is convert the catastrophic kind into the survivable kind: a provider collapse becomes our routing problem, not your frozen funds.

Then be honest about the alternative. “Controlling our own destiny” is only true if you build what we built: several integrations, plus the monitoring that helps you decide when to switch. One direct integration doesn’t remove the single point of failure. It moves it from a company whose entire business is redundancy to a company whose API is the third priority in the building.

And if the residual dependency still bothers you, keep a direct line to one provider for your most critical corridor. Genuinely, you wouldn’t be the first. We’re relaxed about it, because we know where the volume ends up. Redundancy, pricing, and a 3am phone call are hard to beat with a backup pipe.

One last difference, when we have a bad day: your stuck transfer is this entire company’s only business, and everyone here is on it within minutes. At a provider, you’re a ticket in the queue. That routing, and that response, is the product. The integration never was.

You’ll design the abstraction wrong. So did we.

Suppose you accept all of the above and decide to build it properly: not one integration but an abstraction layer, so the next provider is cheap to add. Good instinct. Now one honest question: how do you design the right abstraction over many providers when you’ve seen one?

You can’t. Neither could we. Your abstraction will be a cast of your first provider’s shape. The second provider will crack it. The third will make you rewrite it. We know this sequence by heart, because our own layer went through every one of those painful rewrites, each paid for with production incidents and migration projects. These lessons don’t compress into a blog post, including this one. You have to see the tenth provider’s strange refund model to understand what the first nine were trying to teach you.

It’s like renovating your own apartment. Somewhere in the middle you realize the expert would have been faster and cheaper, and you just had to do it yourself once to believe it. And when something breaks behind the wall you plastered yourself… who do you call?

You’re not adding a feature. You’re starting a second company.

“We’ll integrate ourselves” sounds like an engineering decision. In practice it’s a decision to found a small company inside your company. Beyond the engineers, someone has to reconcile the books and chase stuck money across time zones. Someone has to collect RFIs across providers, and carry the on-call phone, because money moves on weekends and a 24/7 rotation takes three or four engineers even in a quiet month.

None of this is your core business. Every hire and every hour here is subtracted from the thing your company actually exists to do. And your best engineers didn’t join you to babysit reconciliation. That’s not only a budget problem. That’s how you lose them.

MIT's research on enterprise AI puts a number on this: tools built in-house succeed roughly a third as often as tools bought from specialized vendors. And that's the average across ordinary software, not payments, where a bug is someone else's money.

For us it’s the opposite. This is not a second company, it’s the only one. The refund playbooks are written, the reconciliation runs, the benchmarks watch the prices, the abstraction layer is on its Nth rewrite, and the phone numbers answer. When money gets stuck, the fix is not a ticket in a queue. It’s a person at the provider who picks up within the hour, because behind our call stands aggregated volume and years of relationship. That leverage, in emergencies and just as much in pricing, is structural. A single integrator never gets it, no matter how good their code is.

One more thing about Claude, because the objection deserves a straight answer. If AI made this work cheap for you, it made it cheap for us too, and we pass that on. You won’t save money doing the same newly-cheap work without our library of edge cases. AI speeds up whoever holds the map. Claude multiplies expertise. It doesn’t replace it.

Curriculum

Everything in this article is a curriculum, and the curriculum is mandatory. Every company that moves money across borders learns all of it eventually. The only question is the tuition: you can pay it in production incidents, frozen funds, and quarters of lost roadmap, or you can pay it upfront, by taking the full size of the work seriously before committing to it.

Take this article to your engineering team and pull it apart. Estimate the real scope, everything in here: the state machine, the reconciliation, the failover, the on-call rotation, the org chart. Challenge every claim against your own experience. If the answer is still "build", build, and you'll be doing it with open eyes. And if you think we got something wrong, tell us. Every playbook we have started as someone pushing back on what we believed.

But whichever way you decide, some Friday evening a transfer will go missing between two banking systems, and somebody will have to pick up the phone and know who to call on the other end.

Make sure your plan says who that somebody is.