Third-Party Integrations: Types, Costs and What Actually Breaks

Almost no product is built entirely from scratch any more. Payments, maps, email, chat, identity checks, analytics — all of it comes from somebody else’s API. A modern application is mostly glue between services.

Choosing integrations is the easy part. Living with them is the hard part, and that is where most articles on the subject stop. This one covers both: what the common types are, what they cost, and the failures that show up three months after launch when the provider changes something and nobody tells you.

What a third-party integration actually is

An integration means your product asks another company’s service to do something, usually over an API. You send a request, they send back an answer, and your product carries on.

The appeal is obvious. Building your own payment processing takes a year and a licence. Connecting to Stripe takes a week. The same goes for sending email, verifying an identity document, or showing a map.

What you are really buying is someone else’s maintenance work. What you are really selling is a piece of your control.

The integrations most products need

A fintech product typically runs five to ten of these at once, and each one is a dependency that can fail on its own schedule.

What it costs, honestly

Integration cost has three parts, and teams usually budget only the first.

1. Building it. A simple REST integration with good documentation — email, maps, analytics — is a few days. A payment provider with webhooks, refunds and reconciliation is two to four weeks. An old enterprise system with SOAP, a VPN and a PDF specification from 2011 can run for months, and the estimate will be wrong, because nobody can see inside it until they start.

2. Paying for it. Per request, per user, per transaction or a flat subscription. The thing to check is not today’s price but the price at ten times your current volume. Several providers are cheap at the bottom tier and painful at the top, and by then moving away is a project of its own.

3. Keeping it alive. This is the part nobody budgets. APIs change, versions get deprecated, certificates expire, rate limits get tightened. Across a handful of integrations, expect a few engineer-days a month, every month, forever.

What actually breaks

This is the section we would have wanted when we started. Every item here is a failure we have seen reach production on real projects.

The sandbox is not the real thing

Test environments are simplified. They are faster, they never go down, and they often return tidy data the production system would never produce. Teams test against the sandbox for three months, go live, and discover that the real API is slower, rate-limited, and occasionally returns a field as an empty string instead of null.

Before launch, run at least one full flow against production with real credentials and a real, small transaction. It is worth the paperwork.

Rate limits arrive without warning

Your code works perfectly at ten requests a minute. A marketing campaign brings a hundred, the provider starts returning 429, and the feature stops. Worse, a retry loop written without a delay turns one problem into an outage.

Read the published limits before you build, retry with growing delays rather than immediately, and queue the work that does not need to happen this second.

Webhooks are not reliable delivery

A webhook is the provider calling you when something happens — a payment settled, a document was signed. Three things go wrong with them, and all three are common:

• They arrive twice. Most providers guarantee at-least-once delivery, not exactly-once. If your handler is not idempotent, you will ship the order twice.
• They arrive out of order. “Payment refunded” can land before “payment succeeded”.
• They do not arrive at all. Your endpoint was down for ten minutes, the provider gave up after a few attempts, and that order is now stuck in limbo.

The fix is always the same shape: make every handler safe to run twice, record the event id you processed, and run a scheduled job that asks the provider directly about anything that has been pending too long. Never treat a webhook as your only source of truth.

Versions get deprecated while you sleep

Providers announce the end of an API version by email, months ahead, usually to whoever signed up for the account — who may have left the company. Then one morning the calls start failing.

Use a shared mailbox for provider notifications, pin the API version explicitly in your code rather than taking the default, and keep a list of every integration with its version and its renewal date. A spreadsheet is enough.

One slow provider freezes your product

A service that is down is easy — you get an error and handle it. A service that takes forty seconds to answer is much worse: your threads fill up waiting, and a problem in one small feature takes down the whole application.

Set an explicit timeout on every outbound call. Decide what your product does when the answer never comes, and make that behaviour deliberate rather than accidental.

Your secrets end up somewhere they should not

API keys in the repository, in a front-end bundle, in a log line that prints the whole request. All three are routine findings. Keep keys in a secret store, keep them out of logs, rotate them when someone leaves, and give each environment its own.

How to test an integration you do not control

This is the question clients ask us most often about integrations, and the answer has three layers.

Mock the provider for everyday tests. Your regression suite should not call a real payment provider on every pull request — it is slow, it costs money, and it fails when their sandbox has a bad day. Intercept the call and return a fixed response instead. In Playwright that is a few lines:

await page.route('**/api/payment', route =>
  route.fulfill({ status: 200, json: { status: 'approved' } })
);

The same technique gives you the cases that are hard to produce on purpose: a declined card, a timeout, a 500. Those paths are where the bugs are, and without mocking you can almost never reach them.

Check your assumptions against the real API on a schedule. Mocks drift. A small set of tests that runs nightly against the provider’s sandbox tells you when a response shape has changed, before your users do.

Test the failure behaviour, not only the success. For each integration, write down what the product should do when the provider is slow, returns an error, or returns something unexpected. Then test those three cases. Most teams test only the happy path, which is the one case that rarely causes an incident.

Mocking, contract checks and failure-path coverage are standard parts of how we build a suite — see test automation services for how that works in practice.

Choosing a provider: six questions

1. What does it cost at ten times our volume? Not today’s bill.
2. How do they announce breaking changes, and how much notice do we get?
3. Is the sandbox realistic? Does it simulate errors, delays and rate limits, or only success?
4. What happens to our data? Where is it stored, for how long, and does that fit the rules we work under?
5. How hard is it to leave? Can we export what we need, and is there a second provider with a similar interface?
6. What is their actual uptime? Look at the status page history, not the number in the sales deck.

Question five deserves extra weight in payments and identity. Those providers get embedded deepest, and switching later is a project, not a task.

When to build it yourself instead

Integrating is usually right, but not always. Build it in-house when the feature is the thing your customers pay you for; when the provider’s pricing at your expected scale beats the cost of your own engineers; when the data cannot legally leave your systems; or when you need behaviour no provider offers and you would spend more time fighting their model than writing your own.

Everything else — email, maps, analytics, document signing — buy it. Those are solved problems, and solving them again is not where your product wins.

FAQ

How long does a typical integration take?
Days for a simple REST API with good documentation. Two to four weeks for payments, where webhooks, refunds and reconciliation are involved. Longer for old enterprise systems, and those estimates are the least reliable.

Is it safe to rely on a third party for a critical feature?
It is, if you plan for the day it fails. Set timeouts, make your handlers safe to repeat, and decide what the product does while the provider is unavailable. “It just stops” is an acceptable answer for a map; it is not for a payment.

Should we use one provider for everything or the best in each area?
One provider means one contract, one support channel and simpler reconciliation. Best-of-breed usually means better features. For money and identity we lean towards fewer, deeper integrations; for the rest, pick what fits.

Who owns an integration once it is built?
Somebody must, by name. Integrations do not fail loudly — they fail quietly, on a Sunday, because a certificate expired. An unowned integration is a future incident.

Need help with an integration?

We build and test integrations for products where the money is real — payment providers, banking APIs, identity checks and back-office systems. That includes the unglamorous parts: idempotent webhook handling, reconciliation, and a test suite that covers what happens when the other side misbehaves.

Our fintech development and QA and testing pages have the details, or tell us which provider you are connecting to and we will say how long it usually takes.