Skip to main content
Out of Scope

is a payment or crm integration out of scope if it wasn't agreed?

Yes — an integration with a system that wasn't named in your scope is new work, often substantial, because it pulls a third party's API, edge cases, and reliability into your deliverable. The exception is when the integration was implied by a feature you already agreed to build.

Why this answer

Integrations are deceptively large. From the client's side, 'connect it to our CRM' sounds like a switch you flip. From yours, it means learning an external API, handling its authentication, mapping data between two systems, managing failure modes when the third party is slow or down, and testing combinations you can't fully control. None of that lives inside your codebase — you're taking on a dependency whose behavior, documentation quality, and uptime are someone else's responsibility but become your problem to handle gracefully. A payment gateway adds compliance and security surface on top of that. A CRM sync adds data-shape negotiations and ongoing field mapping. When an integration wasn't named in the scope, you priced none of this, and the work it generates rivals or exceeds whole features that were specced. Absorbing it silently means importing an open-ended technical liability into a fixed-fee project.

When the answer flips

It moves toward In Scope when the integration was the obvious mechanism behind a feature you already agreed to deliver. If you scoped 'accept payments on the site,' a payment processor was always implied, even if no specific provider was named — the question becomes which one, not whether. Likewise, if the brief said 'sync signups to their email tool,' the integration is the deliverable. It's genuinely ambiguous when a feature could be satisfied without an integration: 'collect leads' might mean a database you build or a CRM you connect to, and those are very different jobs. When the scope describes an outcome that strictly requires an external system, lean In Scope; when it describes an outcome you could meet on your own, the integration is the client choosing a more expensive path.

What to do next

Before quoting, scope the actual integration, not the client's mental model of it. Read the third party's API docs, note the auth flow, error handling, and any rate limits or sandbox requirements, then estimate against reality. Quote it as its own line item with its own timeline, and flag any recurring cost — some integrations need ongoing maintenance as the third party changes their API. Try: 'Connecting to [system] means working against their API, handling sync failures, and testing the round trip — it's a separate piece of work at [fee], adding [time].' Offer a lighter alternative when one exists: a manual export, a simpler tool, or a phase-two add-on after launch. And set the expectation that you can't guarantee the third party's reliability — you build the connection, but their uptime isn't yours to promise.

Settled reads your contract and gives you the exact verdict for this situation — try it free →

Frequently asked questions

Why is an integration so much work when the service has an API?+

An API is the starting line, not the finish. You still handle authentication, map data between two systems that model the world differently, manage what happens when the third party is slow, down, or returns an error, and test combinations across both systems. A clean API reduces the work but doesn't remove it. The hard parts — failure handling, data mapping, edge cases — exist regardless of how nice the documentation looks.

The client says the tool advertises 'easy integration.' Does that change the price?+

Marketing copy describes the happy path. 'Easy integration' usually means the basic connection is documented, not that the edge cases, error handling, and your specific data shape are solved. You're still responsible for the parts the brochure skips. Quote against the real work, and if the integration genuinely is light once you've read the docs, you can pass that savings along — but decide after reading, not before.

Should I charge for time spent just researching whether an integration is feasible?+

If the research is substantial — reading API docs, testing a sandbox, confirming the third party supports what the client needs — yes, scope it as a paid discovery step. Feasibility work has real value and protects both sides from committing to something that can't be built. For a quick check on a system you already know, fold it into the quote. The line is whether the investigation is a glance or a genuine investment.

Who's responsible if the third-party service goes down after launch?+

Not you, and your agreement should say so. You build and test the connection; you can't control another company's uptime, API changes, or deprecations. State clearly that the integration depends on the third party's continued availability and that adapting to their breaking changes is maintenance work, not warranty. This keeps you from being on the hook for outages you didn't cause and can't fix.

Is a payment integration different from a CRM or analytics one?+

Yes — payments add security and compliance weight that most other integrations don't. Handling card data, meeting the processor's requirements, and getting the failure and refund flows right raise both the effort and the stakes. Price payment integrations higher and scope them more carefully. A read-only analytics tag is near the easy end; a full payment flow sits at the demanding end.

How do I word a contract so integrations don't get assumed?+

List integrations explicitly by name when they're in scope, and add a clause stating that connecting to any external system not named is separately quoted. Because clients often describe outcomes rather than mechanisms, also note that features requiring third-party services depend on those services' capabilities and terms. Naming what's in — and stating that everything else is out — closes the gap between an outcome the client pictures and the integration work it actually takes.

Related reading

Answer scope creep from your actual contract — not a template.

Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.

Try it free →Read the scope creep guide