How do you integrate with banking APIs and systems?

Banking API integration sits at a peculiar intersection of ambition and bureaucracy. You have a product idea that depends on moving money, reading balances, or verifying identities, and the assumption is that somewhere out there, a well-documented API is waiting to slot into your architecture. Sometimes that is true. More often, the API exists but will not let you in, or it exists but imposes constraints that reshape your entire flow, or it does not exist at all and you have to find another way to get the same result.

The technical integration is rarely the hardest part. The harder parts are compliance requirements nobody mentions and systems far more locked down than their documentation implies.

We have worked across enough of these projects to know that the technical integration is rarely the hardest part. The harder parts are the compliance requirements nobody mentions until Apple rejects your app, the payment infrastructure choices that look equivalent on paper but behave very differently in production, and the third-party systems that turn out to be far more locked down than their documentation implies. What follows is a practical account of what banking and financial API integration actually involves, drawn from the specific projects where we have had to solve these problems for real.

The goal here is an honest account of where these projects go wrong, what the warning signs look like early, and how to build a product that handles financial infrastructure without making that infrastructure visible to the people using it.

What Banking API Integration Actually Involves

The phrase "banking API integration" covers a wide range of things that behave quite differently in practice. At one end, you have payment processing through providers like Stripe, which abstract most of the banking relationship away and give you a relatively clean interface. At the other end, you have direct integrations with banks or financial infrastructure providers, which require formal agreements, compliance vetting, and often months of negotiation before a single test call goes through.

API access versus API availability

The distinction that trips up most product teams early is the difference between an API existing and an API being available to them. Open banking regulations have pushed many institutions to publish APIs, but access is often gated behind partnership agreements, minimum transaction volumes, or regulatory status checks. A product that has not yet launched cannot demonstrate volume. A startup without an e-money licence cannot pass the compliance checks. The documentation is public, but the keys are not.

What you are actually integrating

Beyond access, the scope of what "integration" means varies considerably. Payment initiation, account information retrieval, identity verification, fraud scoring, and currency conversion each sit in different parts of the financial stack and often require separate integrations with separate providers. Building a product that touches more than one of these means managing multiple agreements, multiple authentication flows, and multiple failure modes at once. According to Salesforce's Connectivity Report 2023, 99% of organisations report using APIs to integrate applications and data, which reflects how normal this complexity has become, though it does not make that complexity easier to manage.

Why Compliance Must Be Designed In, Not Bolted On

The most expensive lesson in financial product development is learning that compliance requirements change your architecture, not just your paperwork. When compliance is treated as something to handle at the end, after the core flows are built, you end up rebuilding those core flows anyway, at significant cost in time and money. We know this from direct experience, and it shaped how we approach every financial product we work on now.

On a peer-to-peer currency exchange product we built, users could exchange leftover foreign currency with other travellers at interbank rates, avoiding commission. We built the core transfer mechanism well. What we did not factor in was anti-money laundering. Apple specifically flagged the product as a potential vehicle for money laundering because of its unlimited transfer capability. We had to go back and retrofit more stringent KYC checks, enhanced transfer security, and hard limits on the number of transfers permitted between any two parties. That retrofit was far more disruptive than building those controls in from the start would have been.

The compliance requirements that tend to be missed earliest are the ones that feel like edge cases at the product design stage but turn out to be platform-level requirements. App store policies on financial products, AML obligations, and payment scheme rules all sit outside the API documentation and are easy to treat as someone else's problem until they become a rejection or a rebuild. The cost of non-compliance, according to Globalscape's Data Protection Regulations Study, runs at nearly three times the cost of building it in properly from the start.

Before writing a single line of integration code, map every regulatory touchpoint the product will encounter: AML, KYC, payment scheme rules, and app store financial product policies. Treat these as architectural inputs, not legal footnotes.

KYC, AML, and the Limits Nobody Tells You About

KYC and AML requirements exist in every financial product to some degree, but the specific form they take is not always obvious from the API documentation alone. Know Your Customer checks verify that users are who they say they are. Anti-money laundering rules limit how money can flow, between whom, and in what volumes. The challenge is that these requirements are often discovered through rejection rather than guidance.

On the currency exchange product, the unlimited transfer model was the problem. Two users exchanging currency with no cap looked, from a compliance perspective, like a channel for moving undeclared funds. We had to introduce hard limits on how many transfers could occur between any two parties, add a more stringent identity verification layer, and build monitoring logic that flagged unusual transfer patterns. None of this was in the original product brief because nobody had modelled the AML risk at the design stage.

AML requirements are often discovered through rejection rather than guidance, and retrofitting them means rebuilding core flows at full cost.

The limits that catch teams out most often are the ones imposed by platforms rather than regulators. Apple and Google both apply their own financial product policies on top of whatever regulatory requirements already exist. A product that is technically compliant with financial regulation can still be rejected by the App Store if its transfer model looks problematic to the App Review team. Building in transfer limits, identity checks, and monitoring from the start addresses both sets of requirements at once rather than iterating through two separate rounds of rejection.

Model your transfer flows for AML risk before you build them, not after. Ask specifically: could this flow be used to move money between parties in a way that obscures its origin? If yes, add limits and monitoring at the design stage.

When the API You Planned to Use Does Not Exist or Will Not Have You

One of the most disruptive discovery moments in financial product development is finding, midway through a project, that the integration you planned for does not work in the way you assumed. The API may exist but be inaccessible to a new product without an established track record. The provider may not have a usable API at all. Or the systems behind the API may be so fragmented that real-time integration is not viable.

We encountered this directly on a toll management platform project. The assumption going in was that we could integrate directly with toll operators via their APIs. When we got into the detail, we found there was no coherent or consistent API across providers. Each operator worked differently, some accepting cash, some card, with fees varying by vehicle axle count or flat rate. Direct integration was not viable. Our solution was to set up corporate accounts with each toll provider, register customer vehicle plates to those accounts, and have customers preload credit onto the platform. This removed the need for real-time integration entirely.

Part of that project also involved educating the client about the reality of API access for an unproven product. A brand-new platform cannot easily negotiate data-sharing agreements with established operators. We made the case that the smarter move was to launch under the preloaded credit model and pursue API integrations later, once the platform had established credibility. The client accepted this staged approach, and the product launched on that basis.

On a production management tool for the motion picture industry, we initially expected to integrate directly with existing document storage platforms used on productions. When we finally gained access to those systems, they were far more locked down than anticipated. We had to pivot to an alternative approach, ingesting emails tied to specific roles within a production to process data indirectly, without a direct API connection into the third-party platforms.

Choosing the Right Payment Infrastructure for Your Flow

Choosing a payment provider is not just a matter of picking the one with the best documentation. The account type, payout timing, and the degree of control you need over fund flows all affect which option is right for a given product, and the differences between options are more consequential than they first appear.

On a property maintenance platform we worked on, the product connected landlords, tenants, and tradespeople, allowing job specifications to be uploaded, progress to be geotagged, and payments to be released on completion. The flow required holding funds until work was verified, which is effectively an escrow model. We investigated third-party escrow services but found they posed legal complications for the client. By using Stripe Connect with delayed payouts and treating the product as a marketplace app, we achieved the escrow-like outcome while remaining fully compliant. Stripe handled the financial regulation requirements.

Stripe Connect account types

The Stripe Connect account type decision matters more than it looks. On that same project, and on a separate integration where we needed delayed payouts to simulate escrow, we found that Express accounts require near-immediate payouts, which did not suit our use case. The more control you need over payment timing and fund flows, the more complex the integration becomes. The key is finding the point where you get the behaviour you need without over-customising to the point where you lose the benefits of Stripe's default payment handling.

Retrofitting an API Layer onto an Existing System

Inheriting a product that was not built with an API layer is a common situation, and the problems it creates are underestimated almost every time. When a system is tightly coupled, meaning its components communicate internally in ways that were never designed to be exposed externally, adding an API after the fact requires either getting the original developer to do it or finding workarounds that carry their own risks.

On a buying and selling platform for bottles of alcohol, similar in model to wine trading, we had already started building the mobile product when we discovered we could not implement the planned API layer. The client's existing web application had been built by another developer in a way that made it too complex to expose cleanly via an API. We ended up having to embed web elements from the existing site directly into the mobile product instead. The final solution was not as scalable or robust as we would have liked, but it was the restriction we were working within.

On a drinks industry trading platform, we inherited a tightly coupled web product built by a third-party developer with no API layer exposed. Getting timely responses from that developer about how to access data became a significant blocker. Rather than continuing to wait, we took the lead. We wrote the API specification ourselves, worked to that spec, and then had the third-party developer implement it. Taking ownership of the spec broke the deadlock and allowed the project to move forward.

If you are inheriting a system without an API layer, write the spec yourself before approaching the original developer. Having a concrete specification in hand changes the conversation from "can you help us?" to "here is exactly what we need."

Staged Integration: When to Launch Without the API

There is a version of every financial product that can launch without the full integration in place. Finding that version, and being honest with clients about why it is the right starting point, is one of the more underrated skills in product development. A staged approach is not a compromise: it is a way of getting a product in front of real users without depending on integrations that are not ready.

The toll management platform is the clearest example we have. The direct integration with toll operators was not viable at launch for a new, unproven product. The staged approach, using preloaded credit and corporate accounts rather than real-time API connections, got the product to market. The plan was always to pursue API integrations once the platform had established credibility and could negotiate from a position of demonstrated value rather than a cold approach.

The same logic applied on the memory-sharing proof-of-concept project where we initially looked at integrating with Spotify for audio clips. Spotify lacked a robust API for clips, and users would have needed a Spotify account, which damaged the experience. We switched to Deezer, which had a robust API, supported clips, and did not require users to be logged in. People could search a catalogue larger than Spotify's and attach clips within the app.

A further benefit was that when users wanted to hear a full track, there was an upsell to a Deezer subscription, creating affiliate referral revenue as a secondary income stream. Choosing the right integration partner, rather than forcing the originally planned one, simplified both the architecture and the business model.

Serverless Architectures and Webhook Handling

Webhooks are how payment providers tell your system that something has happened: a payment succeeded, a payout was made, a dispute was opened. In a conventional server setup, receiving a webhook is straightforward. The server is running, it listens for incoming requests, and it processes them as they arrive. In a serverless architecture, where functions are spun up on demand rather than running continuously, the same process requires more deliberate design.

On a cybersecurity learning management system project, we integrated Stripe payments with AWS Lambda functions. Getting Lambda to correctly pick up incoming Stripe webhooks and process payments proved initially challenging. Because we were not using a traditional monolithic server, the function had to be configured to trigger reliably on incoming webhook events, handle retries if processing failed, and return the correct response to Stripe so it did not keep resending the same event. We resolved the integration successfully, but the experience confirmed that serverless webhook handling is not a straightforward lift-and-shift from a conventional setup.

What makes webhook handling harder in serverless

The specific challenges are worth naming. Cold start latency can cause a function to respond too slowly, which some providers interpret as a failure. Idempotency matters more in serverless because retry logic is more aggressive, and processing the same event twice can cause duplicate charges or records. Logging and error visibility require explicit setup rather than being available by default. None of these problems are insurmountable, but they each require deliberate attention, and treating a serverless webhook integration as equivalent to a conventional one is how they get missed.

How Third-Party API Changes Break Your Architecture

Third-party APIs change. Providers deprecate endpoints, change authentication methods, alter response structures, or revise their terms in ways that affect what you are allowed to do. When your product depends on external APIs, any of these changes can break flows that were working fine the day before. The question is not whether this will happen, but how much damage it causes when it does.

On a travel product, we integrated with a third-party aggregator at the client's request. Midway through development, the client decided the aggregator's added costs made the product's financial model unworkable. They switched to a different supplier, which used a fundamentally different API approach. This forced us to go back to the drawing board and re-engineer significant portions of the integration layer. Later, the client added a third external service to handle specific bookings, requiring yet another round of integration work. Each change required careful review, rewriting of integration code, and ensuring the new integration was both robust and secure.

The lesson from that project is that integration architecture needs to account for provider changes from the start. An abstraction layer between your core product logic and the third-party API means that when a provider changes, you update the adapter rather than rewriting the business logic. It also means you can swap providers, as we did on the memory-sharing project when we moved from Spotify to Deezer, without rebuilding the entire integration. On that project, switching to Deezer's official API and using it in the way Deezer intended meant full compliance without workarounds, simplifying both the architecture and the compliance position at the same time.

Designing Integration Seams That Feel Invisible to Users

The best integrations are invisible to the people using the product. Users do not care that your identity verification is running through a third-party KYC provider, or that the payment hold is implemented using Stripe Connect's delayed payout model. What they care about is whether the experience feels coherent, fast, and trustworthy. The seams between your product and its integrations should not be visible.

This is harder to achieve than it sounds, particularly when integrations impose steps on the user that the product would not have included by choice. On the film industry production management tool, the biggest challenge of working around the security restrictions of the third-party document platforms was making sure the alternative solution did not feel like an unnecessary extra step. The entire value of integrating with those systems was seamless data pulling. We had to find an approach that felt largely invisible and natural to the user, even though we lacked a direct API connection. The ingestion process via role-specific emails had to be designed so users experienced it as part of the normal workflow, not as a workaround.

On the baby monitor project, we had to formally define a software-hardware contract specifying exactly how the companion app would communicate with the device: turning things on and off, retrieving sensor data, accessing camera feeds, all in a format the app could consume. Getting this contract right was the condition for the user experience feeling seamless. If the contract was wrong, the integration lag or failure would be visible, and visible integration failures destroy trust in a product whose entire purpose is monitoring a child's safety.

Design the user-facing experience of every integration touchpoint before writing the integration code. If a user has to see a loading state, an error message, or an extra confirmation step because of an integration constraint, design that moment deliberately rather than leaving it as an afterthought.

Writing the Spec When Nobody Else Will

Integration projects stall for many reasons, but one of the most common is that nobody has written down what the integration actually needs to do. The product team knows what behaviour they want. The third-party developer or provider knows what their system can do. Without a spec that maps one to the other, both sides are working from assumptions, and the gap between those assumptions only becomes visible when something goes wrong in testing.

On the drinks industry trading platform, the lack of an API layer in the inherited system combined with slow responses from the original developer created a deadlock that was slowing the project significantly. The solution was to take ownership of the specification rather than waiting for someone else to define it. We wrote the API spec, worked to that spec, and then had the third-party developer implement it. This shifted the dynamic entirely. Instead of asking open questions and waiting for answers, we were presenting a concrete target that the developer could implement or push back on. The pushback, when it came, was specific and actionable rather than vague.

1. Define the data your product needs and in what format.
2. Define the actions your product needs to trigger and when.
3. Write these as concrete endpoint specifications, not requirements documents.
4. Share the spec with the third party and invite specific objections.
5. Revise based on what is technically feasible, then lock the spec before building.

This approach works whether you are integrating with a third-party developer, a legacy system, or a banking partner whose API documentation is incomplete. Having a written spec turns a negotiation about what is possible into a conversation about a specific document, and that is a much more productive conversation.

Conclusion

Banking and financial API integration is genuinely complex, and most of that complexity lives outside the technical integration itself. It lives in compliance requirements that reshape your architecture, in API access that is conditional on credibility you do not yet have, in payment infrastructure choices that look equivalent until you hit the constraint that matters for your specific flow, and in third-party systems that turn out to be far more locked down than their documentation suggests.

The projects we have described here, the currency exchange product, the toll management platform, the property maintenance marketplace, the drinks industry trading platform, the film production tool, the serverless LMS, each taught us something specific about where financial integration goes wrong and how to recover when it does. The common thread is that problems discovered late cost more than problems anticipated early, and the ones that cost most are the ones that require rebuilding flows rather than adjusting them.

Building financial products that work means treating compliance as an architectural input, choosing payment infrastructure based on your actual flow requirements, designing for the moment when third-party APIs change, and being willing to write the spec yourself when nobody else will. These are the normal conditions of this kind of work.

If you are working through a financial integration and any of this sounds familiar, let's talk through your integration challenges.

Frequently Asked Questions