If you follow UK tech news, fintech M&A shows up often enough that it's worth planning for as an engineering risk, not just a business one. A few recent examples make the pattern pretty clear.
The pattern shows up more than you'd think
When Visa acquired Plaid in a deal reported at $5.3 billion, the acquisition itself didn't break anything overnight, but it changed the trajectory of the product: enterprise first commercial terms became more prominent, and smaller teams increasingly found onboarding heavier than with leaner competitors.
TrueLayer's own migration from its Payments v2 API to v3 required developers to handle new mandatory request signing and restructure how pay-in creation and authorization were split into separate steps, a non-trivial integration change for anyone on the old version. And GoCardless's acquisition of the open banking provider Nordigen in 2022 came with a scaled-back free tier not long after, which pushed a chunk of smaller developers and indie fintechs to re-evaluate their stack entirely.
None of these are edge cases. If you build on a third-party payments API, at some point you are statistically likely to be on the losing end of an acquisition, a pricing change, or a forced migration.
Practical mitigation, not paranoia
You don't need to avoid third-party payment APIs, that's not realistic, but a few patterns meaningfully reduce your exposure:
Build a thin abstraction layer. Don't let your business logic call the vendor SDK directly from a dozen places in your codebase. Wrap payment initiation, mandate management, and webhook handling behind your own internal interface. When a provider changes its API surface or you need to swap providers, you're editing one adapter instead of hunting through your entire codebase.
Store your own canonical payment state. Don't treat the vendor's dashboard or API as your only source of truth. Persist mandate IDs, payment statuses, and webhook events in your own database, keyed by your internal references, not just theirs.
If a migration forces you to re-point to a new API version, or a new company entirely post-acquisition, you want your historical data intact and queryable without depending on the old vendor's API still working.
Watch for signal, not just announcements. Free-tier scale-backs, slower support response times, and increasingly enterprise-flavored sales conversations tend to precede bigger platform shifts. They're not proof of anything on their own, but they're worth tracking if a huge chunk of your revenue runs through one payment provider.
Budget migration time into your roadmap, even speculatively. Teams that treat "our payments provider might change" as a real possibility instead of a hypothetical tend to handle forced migrations (like the TrueLayer v2 to v3 move) in days instead of months, because the abstraction layer was already there when they needed it.
The underlying lesson isn't really about payments specifically. It's about recognizing that any vendor API you depend on is a dependency with its own business risk attached, and a little architectural distance up front is cheap insurance against a migration you didn't choose the timing of.
Top comments (0)