Which third party integrations require legal agreements

The first time a payment processor flags your app for compliance issues, you learn something quickly: the legal layer of third-party integrations is not a formality you sort out after launch. On a peer-to-peer currency exchange product we worked on, users could swap leftover foreign currency at interbank rates, cutting out commission entirely. The core transfer mechanism worked well. What we had not built in was anti-money laundering compliance.

Apple flagged the product as a potential vehicle for money laundering because the transfer capability was unlimited. We had to go back and retrofit more stringent KYC checks, enhanced transfer security, and hard limits on how many transfers could happen between any two users. The rebuild cost time, money, and goodwill with the client.

Get the legal layer wrong and you are not just fixing code, you are rebuilding trust with regulators, platforms, and users.

That experience, and others like it, shaped how we approach third-party integrations now. Legal agreements and regulatory obligations are not things you attach at the end. They shape what you can build, how quickly you can build it, and sometimes whether you can build it at all.

This article covers the categories of integration that trigger legal obligations, what those obligations actually involve, and how to check them before a single line of code is written.

Why Legal Agreements Get Missed Before Build Begins

Most build processes treat legal as a back-end concern. The product gets scoped, the technical architecture gets planned, the sprint backlog gets filled, and somewhere near the end someone asks about terms of service. By then, choices have been made that are expensive to unwind.

The reason legal gets missed is partly structural and partly psychological. Developers and product managers are focused on what the integration does, not what the integration requires. API documentation describes endpoints, authentication methods, and data formats. It rarely opens with a list of contractual obligations the integrating party must satisfy before going live. Those obligations live in a separate document, often long and written for lawyers, and nobody reads it at the discovery phase.

There is also a category error at play. Teams distinguish between "technical feasibility" and "legal feasibility" as though they are separate questions. They are not. Whether you can legally use a given API, whether you are permitted to process the data it returns, whether the provider requires a formal agreement before you access production credentials: all of these are technical constraints, because they determine what you can ship.

The cost of non-compliance is nearly three times the cost of compliance, according to Globalscape's data protection research. That ratio makes the case for doing this work at the start, not at the end.

Payment Processors: What Stripe, PayPal and Others Actually Require

Payment processors are not neutral utilities. Each one comes with its own legal framework, and the account type you choose within that framework determines what you are and are not allowed to do with money flows.

We found this directly on a project integrating Stripe Connect. Stripe Connect offers several account types, and we initially looked at Express accounts, which are simpler to set up. The constraint is that Express accounts require near-immediate payouts. Our use case needed delayed payouts to simulate escrow behaviour, holding funds until a condition was met before releasing them to the seller. Express accounts could not do that.

Moving to a more controlled account type gave us the payment behaviour we needed, but the integration became significantly more complex. As Simon puts it: the more control you have over the payments, the more complex the flows become. Finding the balance between precise payment behaviour and not losing the benefits of Stripe's default handling took real work.

Beyond the technical constraints, payment processors require legal agreements that go further than clicking "accept terms." Platforms handling payments on behalf of third parties, as in a marketplace model, often need to satisfy the processor that the platform itself is compliant. That means submitting business details, described use cases, and sometimes evidence of regulatory standing before production access is granted.

Check which Stripe Connect account type fits your payment flow before any code is written. Express, Standard and Custom each impose different constraints on payout timing and flow control, and switching mid-build forces a significant re-architecture.

PayPal, Adyen, and others follow similar patterns. The legal agreement you sign determines what the API will permit. Read it before you scope.

Financial Regulation: When Your Integration Triggers AML and KYC Obligations

Some integrations do not just require acceptance of a provider's terms. They trigger statutory financial regulation that sits above any provider agreement. Anti-money laundering law and Know Your Customer requirements apply to any product that moves money in ways that resemble financial services, regardless of how the product describes itself.

This is exactly what happened on the currency exchange product. The product was conceived as a convenience tool for travellers, not a financial service. But the mechanism, users transferring money to other users at interbank rates, looked like a money transmission service to Apple's reviewers and, more importantly, to the underlying regulatory framework. The unlimited transfer capability made it worse. No ceiling on transfers between two parties is a recognised characteristic of money laundering risk.

The retrofit we had to build included three layers. First, stricter identity verification at onboarding so we could reliably tie each transaction to a verified individual. Second, enhanced security around each transfer itself. Third, a hard cap on the number of transfers permitted between any two users. Each of these changes was driven by regulatory obligation, not product preference.

If your product moves money between users, AML and KYC obligations apply before launch, not after rejection.

The lesson is that financial regulation follows the behaviour of the product, not its branding. If your integration allows value to move between parties, take legal advice on whether that triggers AML or KYC obligations before you build the mechanism that moves the value.

Data Protection: GDPR Obligations That Third-Party Integrations Can Create

Integrating a third-party service almost always involves sharing personal data. An analytics tool receives user behaviour data. A CRM receives contact details. A push notification service receives device identifiers. Each of these transfers creates a data processing relationship that GDPR governs, and that relationship requires a formal Data Processing Agreement between you and the third party.

A DPA is not optional where personal data is involved. GDPR penalties can reach €20 million or 4% of global annual revenue, whichever is higher. Most large providers offer a standard DPA, but signing it commits you to the data handling practices it describes, which means you need to read it before you commit.

Third-party integrations also create obligations that interact with each other in ways that are not always obvious. On the anonymous messaging app we worked on, we identified a direct tension between GDPR's right to erasure and the legal requirement to retain data for potential criminal investigations. A user could delete their account after sending abusive messages and expect their data to be removed. But if police later needed to open an investigation, that data had to exist somewhere.

We resolved this by implementing a data retention policy of around six months. Even after account deletion, the underlying message data remained available to law enforcement for that window. This meant we were not ignoring GDPR, but we were also not leaving ourselves legally exposed if a criminal matter arose. Getting that balance required legal input, not just product judgment.

Before integrating any third-party tool that touches personal data, confirm whether a Data Processing Agreement exists, request it, and have it reviewed. Do not assume the provider's standard terms cover your specific use case.

Authentication and Identity: Legal Reasons You Cannot Always Defer Login

In most product contexts, deferring login improves the onboarding experience. Asking users to create an account before they have experienced the product is friction at the worst possible moment. The general principle is to let users explore first and gate account creation behind the point where they have understood the value.

But some products cannot defer login. Not for product reasons. For legal ones.

On the anonymous messaging app, authentication had to sit at the front of the experience, before any messaging was possible. The product presented as anonymous to users, meaning recipients could not see who sent a message. But on the back end, every message had to be tied to a specific, verified user. The reason was legal: if abuse or harassment occurred, we needed to be able to identify the sender and hand that information to law enforcement. A product that allowed anonymous messaging without any back-end identity trail would have been legally indefensible.

This is a category of legal constraint that affects UX directly. The authentication decision was not made by a product manager weighing conversion rates. It was made by a legal requirement around accountability and harm prevention. Any product where anonymous interaction, age-restricted content, or regulated activity is possible needs to take the same question seriously: if something goes wrong, can you identify who did it?

If you cannot answer that question, your authentication design is a legal liability, not a UX choice.

Music, Media and Content Licensing Agreements

Audio and video content carries rights that belong to someone else. Integrating a music library, a video player, or any mechanism that surfaces copyrighted media into your product means your product is distributing that media, and distribution requires a licence.

We encountered this directly on a proof-of-concept project for a company building an app to share memories with audio attached. The initial plan was to integrate with Spotify, allowing users to attach short audio clips to memory posts. Two problems emerged immediately. Spotify's API did not support robust clip functionality in the way the product needed. And users would have been required to hold an active Spotify account, which created unnecessary friction and excluded a large portion of the potential audience.

We switched to Deezer. Deezer had a robust API that supported clips, did not require users to be logged into a Deezer account to search and attach audio, and offered access to a catalogue larger than Spotify's. The licensing terms were clear and the integration was compliant from the start, without workarounds. A further benefit was that when a user wanted to hear a full track, the product could surface an upsell to a Deezer subscription, creating an affiliate revenue stream alongside the core product.

The comparison also illustrated something about compliance and technical complexity. Working with Spotify without a proper API would have required significant custom technical solutions to stay within Spotify's rules. Using Deezer's official API in the way Deezer intended meant the architecture was simpler and the compliance burden was lower.

Incumbent Platforms and Formal Data-Sharing Agreements

Some of the most valuable integrations are the hardest to access. Established platforms, whether in travel, finance, logistics, or any other data-rich sector, hold data that a new product would benefit enormously from consuming. But those platforms have no obligation to share it, and in practice they often will not negotiate data-sharing agreements with an unproven product that has no market presence yet.

We worked through this on a toll management platform. The product needed to integrate with established toll operators to function properly. We had conversations with the client about what it would actually take to negotiate API access with those incumbents, and the honest answer was that a brand-new product with no credibility had very limited leverage. Established toll operators have no commercial reason to fast-track an integration agreement with a startup that may not survive its first year.

The approach we agreed on was to launch using a preloaded credit model that did not require live API access to toll operators. This got the product to market, started building a user base, and gave the company something concrete to point to when approaching incumbents for formal data-sharing agreements later. API integrations would follow once the platform had established enough credibility to make those negotiations realistic.

Formal data-sharing agreements are commercial negotiations, and the other party's willingness to sign depends on whether they see the new product as a partner worth having.

If your product depends on data held by an established platform, map the data-sharing negotiation as a project milestone, not a background assumption. The agreement takes time, requires a credible counterparty, and may not be available at all until you have demonstrated market traction.

App Store Rules as Legal Constraints

App store guidelines are not suggestions. They function as a legal framework that determines whether your product can reach users at all on a given platform. Violating them is a distribution failure, which is often worse than any technical shortcoming.

Apple's review process deserves particular attention. The currency exchange product we worked on faced a situation that went beyond straightforward guideline compliance. After the AML and KYC work was retrofitted and the product resubmitted, Apple continued to raise new objections. Each time a previously flagged issue was resolved, a different issue appeared. The pattern suggested that the underlying problem was not the specific compliance gap but something Apple did not want to permit at all, for reasons that were never formally stated. There is no effective mechanism for a developer to challenge this behaviour. A well-funded incumbent operating in the same space can, in practice, use the review process to slow or block a compliant competitor's access to the market.

Google's Play Store has a different review approach, but both platforms impose rules around financial products, age-gated content, subscription mechanics, and data handling that go beyond what general law requires. A feature that is entirely legal may still be prohibited by store guidelines, and the guidelines change without much notice.

App store rules also affect third-party integrations directly. In-app purchases that bypass Apple or Google's payment systems are prohibited in most contexts. Payment integrations that route subscription revenue outside the store will fail review. This is a legal and commercial constraint that shapes the entire monetisation architecture of a mobile product.

When API Access Is Restricted or Simply Does Not Exist

Legal agreements and technical access are different things, and they do not always arrive together. A platform may grant you a legal right to integrate through a formal agreement while the API itself is limited, or the data you expected to access turns out to be locked behind additional security that the agreement does not address.

On a production management product for the motion picture industry, we expected to integrate directly with existing platforms used for storing production documents and to pull in data via those integrations. When we finally gained access to the systems, they were far more locked down than the pre-build conversations had suggested. The access we needed simply was not there.

We had to pivot. The alternative approach was to ingest emails tied to specific roles within a production, processing data indirectly rather than through a direct API connection. The technical challenge was making this feel invisible to users. The entire value of the integration was that data would appear in the right place without manual input. If the workaround felt like an extra step, it would undermine the product's purpose. We had to build a solution that functioned cleanly from the user's perspective while operating on a fundamentally different technical basis than originally planned.

Restricted API access also has a budget consequence. On an alcohol buying and selling platform, being forced to embed web elements instead of building a proper API layer added approximately 20% uplift in work across the entire length of the project. Because the client wanted to hold the budget, features had to be dropped at the end to compensate. A constraint that looks purely technical creates a commercial trade-off.

How Switching Providers Mid-Build Compounds Legal Risk

Switching a third-party provider mid-build is almost always more expensive than it looks at the point the decision is made. The technical cost is one part of it. The legal cost is the other, and it tends to be invisible until the new provider's agreements land on the table.

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 cost model made the financial case for the whole product unworkable. They switched to a different supplier. The two suppliers used fundamentally different API approaches, which meant going back and re-engineering significant portions of the integration layer. Later, a third external service was added to handle a specific category of bookings, requiring another round of integration work. Each change required careful review, rewriting of integration code, and ensuring the new approach was as robust and secure as the original.

Each new provider also brought its own legal agreements. Terms that the previous provider did not require. Data handling obligations that were different in scope. Review periods that added days to a timeline that was already under pressure. The legal review process for each new agreement is not long, but it is not zero either, and when it happens three times in a single project, the cumulative effect on timeline and budget is real.

The practical implication is that provider selection is a legal decision as much as a commercial and technical one. Changing providers is a question of what the new provider requires you to agree to, and whether those requirements are compatible with commitments already made to other parties in the product ecosystem.

A Practical Pre-Build Checklist for Third-Party Legal Obligations

The questions below should be answered before the first integration is scoped. Some will require legal input. All of them are cheaper to answer at the start than to discover mid-build.

1. Does the provider require a formal agreement before production access is granted, separate from the standard terms of service?
2. Does your use of the API fall within the permitted use cases described in the provider's documentation and legal terms?
3. Does the integration involve transferring personal data? If so, is there a Data Processing Agreement in place?
4. Does the product move money between users or between users and third parties? If so, has a solicitor confirmed whether AML or KYC obligations apply?
5. Does the product surface audio, video, or other copyrighted content? Is there a content licence in place?
6. Does the product rely on data held by an established platform? Has a data-sharing agreement been negotiated, or is there a staged plan to pursue one?
7. Is the product distributing through Apple or Google's app stores? Have the store guidelines been reviewed against every feature, not just the primary use case?
8. If any provider is switched during the build, has the new provider's legal agreement been reviewed before integration work restarts?

Legal obligations follow behaviour, not branding: build the mechanism first and the regulation finds you.

Run this checklist with whoever is leading legal review and whoever is leading technical architecture in the same room. The answers affect both.

Conclusion

Third-party integrations are where a lot of the real complexity in a build lives, and the legal layer of that complexity gets underestimated more often than any other. The currency exchange product that needed AML retrofitting, the anonymous messaging app where authentication was a legal requirement rather than a UX choice, the travel product where switching providers mid-build triggered three separate rounds of legal review: each of these was a situation where the legal question arrived after the technical work had started, and the cost of that sequencing was real.

The pattern across all of these is consistent. Legal obligations follow what the product actually does, not what it is called or how it describes itself. A product that moves money is subject to financial regulation regardless of whether it uses the word "payments." A product that stores messages from identifiable users is subject to data retention obligations regardless of whether it describes itself as anonymous. A product that surfaces audio is distributing that audio under copyright law regardless of whether the UI feels like a music app.

Getting ahead of these obligations is not complicated. It requires asking the right questions before build begins, reading the agreements that come with every integration, and taking legal advice on the categories that warrant it. The alternative is discovering the gap at the worst possible moment, under time pressure, with money already spent.

If you are scoping a product that involves third-party integrations and you want to work through the legal layer before it becomes a rebuild, let's talk through your integration plans.

Frequently Asked Questions